如何将多表SQL连接转换为.NET Core 2.0下基于DbContext的LINQ查询

你写的这段查询无法达到预期，本质是两个可复现的基础问题：

• 跨DbContext的连接无法实现服务端SQL级联查：_context和_configContext是两个独立的数据库上下文实例，各自管理独立的数据库连接、查询生命周期，EF Core 2.0根本不支持把两个不同上下文的数据源拼接成可下推到数据库执行的SQL join逻辑。直接写跨上下文join，运行时要么抛翻译异常，要么会偷偷把两个表的全量数据全部拉到应用内存里做本地匹配，性能损耗极高。
• 连接键的类型转换无法被EF Core 2.0正确翻译：你在连接条件里给s.Id直接调用ToString()做字符串转换，这是C#客户端层面的方法，EF Core 2.0没有内置对应逻辑把这个方法转成数据库层面的类型转换语句，最终查询会直接退化为内存操作，甚至因为两边字段类型排序规则不匹配导致关联结果完全不准。

场景1：两个表实际部署在同一个数据库实例下 #

这种情况优先调整上下文结构，不要人为拆分同库的表到两个不同的DbContext里，直接把两个表的DbSet统一注册到同一个上下文后，按以下规则写连接查询：

• 不要在连接键里直接写无翻译能力的ToString()，如果两边Id字段类型确实不一致（比如Table1的Id是整数类型，Table2的Id是存储同值的字符串类型），使用EF Core可识别的类型转换方法做键值匹配，这类转换会被正确翻译成数据库端的CONVERT语句：

  var queryResult = from s in _context.Table1
                    join f in _context.Table2
                      on EF.Functions.Cast(s.Id, typeof(string)) equals f.Id
                    select new { SourceRow = s, RelatedRow = f };
  

• 执行查询时可以按需加过滤条件、做字段投影，不要一次性把全表数据加载到内存。

场景2：两个表确实分属不同数据库，无法合并DbContext #

这种场景没法实现真正的数据库端多表join，必须拆分查询步骤做内存匹配，同时要严格控制单次拉取的数据量，避免全表扫描拖垮应用和数据库：

1. 先从第一个上下文加载Table1的目标数据，提前加好必要的过滤条件，不要拉全表
2. 提取用来做关联匹配的Id值列表，转换为Table2侧Id对应的类型
3. 用这个Id列表作为过滤条件，从第二个上下文加载Table2的关联数据
4. 在内存中完成两个集合的匹配连接，示例代码：

   // 加载Table1的有效数据
   var table1Rows = _context.Table1.Where(/* 你的业务过滤条件 */).ToList();
   // 提取匹配用的Id集合
   var matchIdList = table1Rows.Select(s => s.Id.ToString()).ToList();
   // 根据Id集合筛选Table2数据，避免全表拉取
   var table2Rows = _configContext.Table2.Where(f => matchIdList.Contains(f.Id)).ToList();
   // 内存中完成连接匹配
   var finalResult = from s in table1Rows
                     join f in table2Rows on s.Id.ToString() equals f.Id
                     select s;
   

• 所有写在连接条件里的表达式，必须是能被EF Core 2.0翻译为SQL语句的逻辑，自定义方法、无翻译能力的客户端操作都会导致查询从服务端join退化为内存匹配，数据量较大时会直接引发内存溢出
• 永远不要直接写跨DbContext的join语句，EF Core 2.0没有跨上下文查询组合的能力，这类写法的执行结果永远不符合预期
• 实现左连接逻辑时，使用LINQ查询语法的into子句搭配DefaultIfEmpty()方法，不要加载全量数据后在内存中判断空值来模拟左连接效果

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