LINQ查询为何先转Expression Tree，是否由数据库提供程序编译为SQL？

我们知道LINQ to SQL查询不会在C#程序内部执行，而是会被翻译为SQL语句后发送至数据库服务器执行。例如如下LINQ查询：

var query = from c in db.Customers
            where c.City == "Nantes"
            select new { c.City, c.CompanyName };

该查询会首先被翻译为如下SQL语句，再在数据库服务器上执行：

SELECT [t0].[City], [t0].[CompanyName]
FROM [dbo].[Customers] AS [t0]
WHERE [t0].[City] = @p0

为什么不直接让C#编译器将LINQ查询编译为SQL，而是要引入表达式树作为中间层？ #

主要有三个核心原因：

• 可扩展性要求：C#是通用编程语言，编译器不能和特定存储技术绑定。除了各类关系型数据库之外，目前生态里还有大量NoSQL数据库、自定义数据源需要支持LINQ查询，如果将SQL编译逻辑硬编码到编译器中，会完全锁死LINQ的扩展能力，第三方也没法为自己的存储系统适配LINQ查询能力。
• 动态查询需求：绝大多数业务场景下的查询是动态拼接的，比如要根据前端传入的筛选条件、排序规则动态调整查询逻辑，这些逻辑是编译期完全无法预知的，只有运行时才能拿到完整的查询结构。表达式树是运行时可遍历、可修改的结构化数据，刚好能支撑动态查询的需求。如果编译器直接编译为固定SQL，动态拼接查询的能力就完全丢失了。
• 多数据库方言适配需求：不同数据库的SQL语法存在不少差异，比如SQL Server、MySQL、PostgreSQL的分页语法、内置函数语法都有区别，C#编译器不可能内置所有数据库的方言适配逻辑，引入独立的中间层才能解耦编译器和数据库方言的绑定。

表达式树的处理是不是由具体数据库提供程序完成的？ #

是的，该理解完全正确。
以EF Core生态为例：

• EF Core核心公共库只负责将用户编写的LINQ查询转换为标准化的表达式树，提供公共的表达式树解析基础能力，不会绑定任何具体数据库的逻辑。
• Microsoft.EntityFrameworkCore.SqlServer、Microsoft.EntityFrameworkCore.MySql这类具体的数据库提供程序，才会负责把通用表达式树转换为对应数据库方言的SQL语句，同时处理对应数据库的特有语法适配、参数化规则、返回结果映射等逻辑。
• 即使是非SQL类的存储系统，适配LINQ的逻辑也是一致的，比如MongoDB的EF Core提供程序就是将表达式树直接转换为MongoDB的BSON查询语句，不需要生成SQL。

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