LINQ to SQL查询SQL Server视图能否获得与查询表一致的执行优化？

问题结论 #

可以实现条件推送至数据库端，生成和原生SQL等效的优化执行计划。

核心原理 #

• LINQ to SQL的IQueryable提供者会将整个查询的表达式树翻译为完整SQL发送到数据库，你对视图实体添加的Where过滤逻辑，会被自动拼接为视图查询外层的WHERE子句，不会在应用层做过滤。
• 数据库自带的查询优化器会触发「谓词下推」优化，将外层过滤条件拆解后下推到UNION的两个子查询中执行，不会先计算全量UNION结果再过滤，最终执行效率和你原有手写的带WHERE的UNION SQL完全一致。

快速验证方法 #

你可以在调试阶段直接输出生成的SQL确认逻辑符合预期：

// 你的视图映射后的IQueryable对象
IQueryable<YourViewEntity> viewQuery = db.YourUnionView;
// 添加过滤条件
var filteredQuery = viewQuery.Where(v => /*你的conditions1、conditions2逻辑*/);
// 输出最终生成的SQL
string generatedSql = filteredQuery.ToString();

查看generatedSql的内容即可确认过滤条件是否被正确推送到数据库侧。

注意事项 #

• 必须直接对LINQ to SQL映射的视图对应的IQueryable对象添加过滤条件，不要提前调用ToList()、AsEnumerable()等方法将数据拉到内存后再过滤，否则会丢失条件推送能力。
• 如果你所在团队有必须使用DataView的约定，只要调整操作顺序即可满足要求：先对IQueryable添加所有过滤条件，再将查询结果填充到DataView中，不要直接加载全量视图数据到DataView后再做内存过滤，就能同时符合开发规范和性能要求。

内容的提问来源于stack exchange，提问作者Timofeus