EFCore查询语句生成流程、让EFCore支持批量Update/Delete/MergeInto

引子

之前发现了一款叫 EFCore.BulkExtensions 的 nuget 包。里面提供了大量的 BulkInsertOrUpdateOrDelete 和 BatchUpdate 的拓展，可以很方便的解决批量更新和删除的问题，不用让 EFCore 一条一条的删除和更新。

其中几个比较有用的函数签名是

Task<int> BatchDeleteAsync(this IQueryable<T> queryable);
Task<int> BatchUpdateAsync(this IQueryable<T> queryable, Expression<Func<T, T>> updateExpression);

但是在升级到 ASP.NET Core 3.1 的时候，所有 Where 中的 someArray.Contains(i.Key) 全部挂掉了。而我的程序里用这一语句比较多，遂下载了其源代码并合并了当时作者几个月都没合并的一个PR。

研究代码，总结了该程序的基本运行过程：

通过反射获取各种私有变量来访问到 DbContext
updateExpression 由这个包自己访问表达式树获得
让 IQueryable 执行 GetEnumerator 让 EFCore 生成对应的 Select 语句，进行字符串拼接
由 DbContext.Database.ExecuteSqlRaw 来完成语句执行

但是这过程有几个问题：

有几种句式 updateExpression 会翻译不了
由其原来实现的 updateExpression 翻译后的某些参数的 SQL 类型不对
我需要一个 INSERT INTO SELECT FROM 的句式，它不支持
我需要一个 upsert 功能，但是原来的 BulkInsertOrUpdate 不能在原表基础上操作

遂研究 IQueryable.Provider.Execute<T> 是什么执行流程。

语句生成过程

我觉得在翻代码的过程中，有这么一首歌比较符合我的心情：如果你愿意一层一层一层一层的拨开我的心，你会发现，你会讶异，你是我最压抑最深处的秘密。

调用 QueryCompiler.ExtractParameters，将其中的闭包捕捉变量参数化
检查是否已经缓存了这个查询表达式，如果没有则转入 QueryCompilationContext 处理，否则转到8
QueryTranslationPreprocessor 处理，在原来的表达式树上先跳舞
QueryableMethodTranslatingExpressionVisitor 将原来的表达式树翻译成一个 ShapedQueryExpression，而这一个表达式则包含了几个部分：SelectExpression、ShaperExpression 和 ResultCardinality。其中前者是可以翻译成 SQL 语句的表达式，中间的是将查询出来的元组映射到实体类型，最后一个是查询的维度（Enumerable、Single、SingleOrDefault）
QueryTranslationPostprocessor 处理，其中比较重要的是将查询的字段加入 SELECT 的 Projection 列表
ShapedQueryCompilingExpressionVisitor 将 ShapedQueryExpression 缓存，并转换成为 IRelationcalCommandCache，然后构造一个 QueryableEnumerable 的 NewExpression。前者包含了该查询语句需要的参数、查询语法树、查询字符串，后者是进行语句执行的类
将上述 NewExpression 和将 QueryCompilationContext 中的查询参数加到 QueryContext 中的语句合并成为一个代码块，然后 Lambda Compile
生成 DbCommand 由 IRelationcalCommandCache 获取字符串并加入各种参数进行查询

翻译结束了，查询到这里也就可以开始了。

支持批量操作？

IRelationalCommandCache 是怎么生成字符串的呢？没错，就是 QuerySqlGenerator 啦。

那么，也就是说，我们能过拿到 Select Expression 的话，一切都好说。

上述过程中，最后的 IRelationalCommandCache 中会包含这个 SelectExpression。我们可以魔改这个啊！

DELETE 语句的生成比较简单。我们构建一个 DeleteExpression 类，将要删除的 Table、删除中的 Predicate、删除个数限制 Limit、原来的一些 Join 全部获取出来，就好了。然后在我们自己继承的 SqlServerQuerySqlGenerator 中实现这个部分。

INSERT INTO SELECT 也比较简单，只要构建一个 InsertIntoSelectExpression 类，将要插入的表 Table 和 SelectExpression 保存起来，就好了。

UPDATE SET 可能比较麻烦。但是我们可以骚操作啊！将那个 updateExpression 变成 Select 的字段，然后再读取 SelectExpression 中的 ProjectionExpression 不就好了吗~我真是个小天才。

MERGE INTO 是最烦的，因为结构过于复杂，涉及到 Target、Source、JoinPredicate、Limit、Matched、NotMatchedByTarget、NotMatchedBySource。过程中还要实现一些表的更名之类的。目前我只是实现了这些，但是想做出 Matched When 功能以后再发布到 nuget 上，这个实现实在是过于复杂，不知道有没有人帮帮我啊 TAT。

由于翻译 SqlExpression 最方便还是基于 QuerySqlGenerator 操作，所以就写一个 EnhancedQuerySqlGenerator 类来满足我们的需求，并在 DbContextOptionsBuilder 那边将这个 Factory 替换掉。

实现了这些，GitHub 地址：Microsoft.EntityFrameworkCore.Bulk，可以在 github packages 上下载目前版本的 nuget 包。

另外 src/Internal/TranslationGoThrough.cs 中有上述语句生成过程的一个缩影，和系统版本几乎一致，唯一不同的是修改了 ExtractParameters 函数。

因为原来的 Extract 过程有一个事情很诡异：在生成参数的时候，我们可以进行一些本地执行，但是如果不阻止某些本地执行程的话，可能会导致 UPDATE 语句的字段全部空。例如 updateExpression 中没有利用到原表的参数并且不捕捉闭包变量的时候，那么不会被本地执行，但是如果没有利用到原表的参数还捕捉闭包变量的时候，它就会被直接本地执行，字段空啦~（确实不懂他们这段代码逻辑怎么写的，你生成查询的时候优化这个的话，怎么不把前面一个也优化掉啊……

原文地址：https://www.90yang.com/efcore-query-sql-generation/