这些查询中的哪一个最有利于性能？

Question

这些查询中哪些最有利于性能？有时我想知道 SHORT 脚本是否真的是最好的关注点。这些脚本执行相同的任务。通过左连接，我只需几行就可以实现我想要的。但后来我尝试使用更长的脚本，使用联合。哪种方法最好？在这之间：

SELECT p.productID, p.product, C.color, C.colorID, S.size, S.sizeID, q.qty From quantities q
        INNER join products P ON p.productID = q.productID
        LEFT JOIN colors C ON C.colorID = q.colorID
        LEFT JOIN sizes S ON S.sizeID = q.sizeID
        --WHERE q.productID = @productID 

和这个：

SELECT p.productID, p.product, C.color, C.colorID, S.size, S.sizeID, q.qty From quantities q
        inner join products P ON p.productID = q.productID
        INNER JOIN colors C ON C.colorID = q.colorID
        INNER JOIN sizes S ON S.sizeID = q.sizeID
        --WHERE q.productID = @productID 
    UNION 
    SELECT p.productID, p.product, NULL, NULL, S.size, S.sizeID, q.qty From quantities q
        inner join products P ON p.productID = q.productID
        INNER JOIN sizes S ON S.sizeID = q.sizeID
    WHERE /* q.productID = @productID AND */ q.sizeID IS NOT NULL AND q.colorID IS NULL
    UNION
    SELECT p.productID, p.product, C.color, C.colorID, NULL, NULL, q.qty From quantities q
        inner join products P ON p.productID = q.productID
        INNER JOIN colors C ON C.colorID = q.colorID
    WHERE /* q.productID = @productID AND */ q.colorID IS NOT NULL AND q.sizeID IS NULL
    UNION
    SELECT p.productID, p.product, NULL, NULL, NULL, NULL, q.qty From quantities q
        inner join products P ON p.productID = q.productID
    WHERE /* q.productID = @productID AND */ q.colorID IS NULL AND q.sizeID IS NULL

编辑：

SQL Server 解析和编译时间：CPU 时间 = 32 毫秒，经过时间 = 65 毫秒。

（受影响的 10 行）表“大小”。扫描计数 1，逻辑读取 21，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。表 'colors'。扫描计数 1，逻辑读取 21，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。表 'products'。扫描计数 0，逻辑读取 20，物理读取 1，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。表 'quantities'。扫描计数 1，逻辑读 2，物理读 1，预读 0，lob 逻辑读 0，lob 物理读 0，lob 预读 0。

SQL Server 执行时间：CPU 时间 = 0 毫秒，已用时间 = 12 毫秒。

（受影响的 10 行）表“产品”。扫描计数 0，逻辑读取 20，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。表 'quantities'。扫描计数 4，逻辑读取 8，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。表 'Worktable'。扫描计数 0，逻辑读取 0，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。表“大小”。扫描计数 0，逻辑读取 18，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。表 'colors'。扫描计数 0，逻辑读 12，物理读 0，预读 0，lob 逻辑读 0，lob 物理读 0，lob 预读 0。

SQL Server 执行时间：CPU 时间 = 0 毫秒，已用时间 = 0 毫秒。

在我看来，这是对性能最好的第二个查询，更大的联合查询。

你们有没有人知道为什么会发生这种情况，或者我是否必须提供更多信息（表格信息等）？

执行计划：

谢谢！

Answer 1

有时我想知道 SHORT 脚本是否真的是最好的关注点。

脚本的大小与查询执行的效率无关。就编译而言，更紧凑的语句可能会消耗更少的资源，但（重新）编译在实时系统中通常很少发生。

然而，较少的表访问通常是可取的，这确实会导致更紧凑的代码。

一般来说，较小的执行计划会产生更好的结果，而较低的估计成本会产生更好的结果。不过，这又是高度情境化的。特别是成本估计可以这样关闭在某些情况下。衡量实际执行时间很重要，因为在一天结束时，这才是最重要的。

通过左连接，我只需几行就可以实现我想要的。但后来我尝试使用更长的脚本，使用联合。哪种方法最好？

首先，我们需要知道在真实系统中这些表中会有多少数据。现在有这么小就很难使用STATISTICS TIME性能指标，以找出一个胜利者-也说回来会受到各种因素所主导的结果其他比执行查询。有了更多数据，计划很可能会发生变化，因此这里的比较没有实际意义。

话虽如此，通过从逻辑的角度来看现在的查询计划，第一个是赢家。

可以看到 Clustered Index Scan ofquantities在第一个计划中出现了一次，而在第二个计划中出现了四次。由于使用UNIONs ，第二个计划还包含一个昂贵的 Distinct Sort （可以通过使用UNION ALLs 来消除该运算符，这不会改变结果）。

在第一查询也很可能得到改善，通过获取指标在寻求colors和sizes表而不是表扫描。这可能是值得尝试的哈希比赛计划，以及（这是什么，你可能会看到当quantities和products较大），但对表这个小，启动成本可能是太多的开销是有益的。

我建议您做的是在循环中运行要测试 10,000 多次的每个语句，计算平均执行时间，然后进行比较。