Question

这是SQL查询语句：

SELECT p.id, p.[name], SUM(ps.sales_amount) AS GROSS_SALES
FROM products p
  LEFT OUTER JOIN product_sales ps ON p.id = ps.product_id
GROUP BY p.id, p.[name]

优于：

SELECT SUM([t2].[value]) AS [SalesAmount], [t2].[id] AS [ProductId], [t2].[name] AS [ProductName]
FROM (
    SELECT (
        SELECT SUM([t1].[sales_amount])
        FROM [dbo].[product_sales] AS [t1]
        WHERE [t1].[product_id] = [t0].[id]
        ) AS [value], [t0].[id], [t0].[name]
    FROM [dbo].[products] AS [t0]
    ) AS [t2]
GROUP BY [t2].[id], [t2].[name]

第二个是LINQ2SQL查询的结果。仍在寻找重写LINQ表达式的方法......

示例中最优化的SQL查询是什么？

你的想法？谢谢！

Answer 1

嗯，第一个查询更好，因为它更具可读性。但是，由于生成了第二个查询而不是解释它，因为您不会（不应该）处理从LINQ表达式生成的实际SQL，因此第二个查询可能没有问题。

我认为SQL Server引擎可以将其展平为标准连接，就像第一个查询一样。如果您想知道如何启动SQL Server Management Studio并查看两者的实际执行计划。

Answer 2

作为一般性陈述，这似乎是一个相当滥用的子查询，并在此基础上我预测第一个查询会更快。为什么不尝试看看呢？

Answer 3

第一个更有效率。通常，连接比子查询更好。 MS-sql并不总是将子查询优化为其逻辑“连接”等价物。查询是如此之小，但要么要么相当好，它可能没有区别。您需要查看查询计划以查看差异，或者查看使用跟踪执行这两者。

第一个当然也更具可读性。这就是您最近使用Linq-to-SQL获得的内容。当然，重点是你不应该自己处理sql。

故事是由Linq-to-Sql生成的查询将变得越来越有效。

Answer 4

我的预感是两者都应该是相同的，性能方面的。左连接可能是嵌套循环连接，这正是子查询版本将要执行的操作。

但是不要相信我的意思 - 正如其他人所建议的那样，查看执行计划，亲眼看看哪一个更好。或者打开客户端统计信息，看看哪一个需要更长时间。

Answer 5

真正的答案是没有测量就无法分辨。即便如此，除非你测量一个真实的数据集，否则你真的不知道。

查看这个blog post（不是我），生成的sql看起来更糟，但表现更好。他的例子专门处理子选择和连接，所以我认为它与你的情况非常相关。

哪个SQL查询更好？

5 个答案: