注意性能:
我至少在EF Core上经历过,这里给出的不同答案可能会导致不同的性能。我知道OP询问了有关Linq to SQL的问题,但在我看来EF Core也出现了同样的问题。
在我必须处理的特定情况下,Marc Gravell的(在语法上更好)的建议导致了交叉应用内的左连接-与Mike U所描述的类似- 结果是,此特定查询的估计成本为2是没有交叉连接的查询的两倍。服务器执行时间相差3倍。[1]
Marc Gravell的解决方案导致查询没有交叉联接。
内容:本质上,我需要在两个表上执行两个左联接,每个左联接又需要联接到另一个表。此外,我还必须在需要应用左联接的表上指定其他where条件。另外,我在主表上有两个内部联接。
估计的运营商成本:
- 交叉申请:0.2534
- 无交叉申请:0.0991。
服务器执行时间(以毫秒为单位)(查询执行10次;使用SET STATISTICS TIME ON测量):
- 交叉应用:5、6、6、6、6、6、6、6、6、6
- 不交叉申请:2,2,2,2,2,2,2,2,2,2
(对于两个查询,第一次运行都比较慢;似乎已缓存了一些内容。)
桌子尺寸:
- 主表:87行,
- 左连接的第一个表:179行;
- 左连接的第二个表:7行。
EF Core版本:2.2.1。
SQL Server版本:MS SQL Server 2017-14 ...(在Windows 10上)。
所有相关表仅在主键上具有索引。
我的结论:始终建议您查看生成的SQL,因为它可能确实有所不同。
[1]有趣的是,当在MS SQL Server Management Studio中设置“客户端统计信息”时,我会看到相反的趋势。也就是说,最后一次没有交叉应用的解决方案花费了超过1秒钟的时间。我想这里可能出了问题-可能是我的设置出现了问题。