a=0 and b=0 and ... z=0 vs a+b+c+d=0 的性能

Question

这是一个我似乎无法找到答案的简单问题。

在性能方面，如果我有一个WHERE条款，例如a=0 and b=0 and ... z=0，如果我用 替换该条件，我会获得任何性能a+b+...+z=0吗？

换句话说，通过替换以下内容是否有任何性能提升

Select * 
From MyTable 
Where A=0 and B=0 and C=0 and D=0...

和

Select * 
From MyTable 
Where A+B+C+D=0...

我知道它可以依赖于索引，但为此目的，我们只说不存在索引。算术运算符 (+) 的性能是否比“OR”或“AND”逻辑运算符更好？

我的印象是加法比使用 AND 或 OR 的多个条件表现得更好。

检测结果

在 420 万行的表上

返回行其中 A=0 B=0 和 C=0 -> 351748 行

添加 (A+B+C=0) 需要 5 秒，而逻辑条件 A=0 和 B=0 和 C=0 需要 11 秒。

另一方面

返回行 其中 A<>0 B<>0 或 C<>0 -> 3829750 行 58 秒

返回行 F65+ F67+f64<>0 -> 3829750 行 57 秒

对于OR，似乎没有显着差异。

我同意 gbn：

如果 A 为 -1 且 B 为 1，则 A+B=0 但 A=0 且 B= 0 为假

和 AMtwo：

ABS(A)+ABS(B)+ABS(C)+ABS(D)... 即使您只期望正值，如果该列接受负值，您应该假设您可能会遇到一个

结果很令人印象深刻，正如我所想的那样，似乎加法比逻辑运算符要快得多。

A = 浮动，B = 货币，C = 浮动。使用的查询如图所示。就我而言，都是正数。没有索引。在我看来，加法比逻辑条件更快是合乎逻辑的！

Answer 1

在您的问题中，您详细说明了您准备的一些测试，在这些测试中您“证明”了加法选项比比较离散列更快。我怀疑您的测试方法可能在几个方面存在缺陷。

首先，您需要确保您没有测试 SQL Server Management Studio（或您使用的任何客户端）。例如，如果您SELECT *从一个包含 300 万行的表中运行 a ，您主要是在测试 SSMS 从 SQL Server 中提取行并将它们呈现在屏幕上的能力。你最好使用类似这样的东西SELECT COUNT(1)，它不需要在网络上拉出数百万行，并将它们呈现在屏幕上。

其次，您需要了解 SQL Server 的数据缓存。通常，我们测试从存储读取数据以及从冷缓存（即 SQL Server 的缓冲区为空）处理该数据的速度。有时，使用热缓存进行所有测试是有意义的，但您需要明确地考虑到这一点。

对于冷缓存测试，您需要在每次运行测试之前运行CHECKPOINT和DBCC DROPCLEANBUFFERS。

对于您在问题中询问的测试，我创建了以下测试台：

IF COALESCE(OBJECT_ID('tempdb..#SomeTest'), 0) <> 0
BEGIN
    DROP TABLE #SomeTest;
END
CREATE TABLE #SomeTest
(
    TestID INT NOT NULL
        PRIMARY KEY 
        IDENTITY(1,1)
    , A INT NOT NULL
    , B FLOAT NOT NULL
    , C MONEY NOT NULL
    , D BIGINT NOT NULL
);

INSERT INTO #SomeTest (A, B, C, D)
SELECT o1.object_id, o2.object_id, o3.object_id, o4.object_id
FROM sys.objects o1
    , sys.objects o2
    , sys.objects o3
    , sys.objects o4;

SELECT COUNT(1) 
FROM #SomeTest;

这会在我的机器上返回 260,144,641 的计数。

为了测试“加法”方法，我运行：

CHECKPOINT 5;
DBCC FREEPROCCACHE;
DBCC DROPCLEANBUFFERS;

SET STATISTICS IO, TIME ON;
GO
SELECT COUNT(1)
FROM #SomeTest st
WHERE (st.A + st.B + st.C + st.D) = 0;
GO
SET STATISTICS IO, TIME OFF;

消息选项卡显示：

表'#SomeTest'。扫描计数3，逻辑读1322661，物理读0，预读1313877，lob逻辑读0，lob物理读0，lob预读0。

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

对于“离散列”测试：

CHECKPOINT 5;
DBCC FREEPROCCACHE;
DBCC DROPCLEANBUFFERS;

SET STATISTICS IO, TIME ON;
GO
SELECT COUNT(1)
FROM #SomeTest st
WHERE st.A = 0
    AND st.B = 0
    AND st.C = 0
    AND st.D = 0;
GO

SET STATISTICS IO, TIME OFF;

再次，从消息选项卡：

表'#SomeTest'。扫描计数3，逻辑读1322661，物理读0，预读1322661，lob逻辑读0，lob物理读0，lob预读0。

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

从上面的统计数据中您可以看到第二个变体，离散列与 0 相比，经过的时间缩短了约 10 秒，CPU 时间减少了约 6 倍。我上面的测试中的长时间持续时间主要是从磁盘读取大量行的结果。如果将行数减少到 300 万，您会看到比率保持不变，但经过的时间明显减少，因为磁盘 I/O 的影响要小得多。

使用“添加”方法：

表'#SomeTest'。扫描计数3，逻辑读15255，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。

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

使用“离散列”方法：

表'#SomeTest'。扫描计数3，逻辑读15255，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。

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

什么会对这个测试产生真正的巨大影响？一个合适的索引，例如：

CREATE INDEX IX_SomeTest ON #SomeTest(A, B, C, D);

“加法”方法：

表'#SomeTest'。扫描计数3，逻辑读14235，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。

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

“离散列”方法：

表'#SomeTest'。扫描计数 1，逻辑读取 3，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。

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

每个查询的执行计划（上面的索引就位）非常有说服力。

"addition" 方法，它必须执行整个索引的扫描：

以及“离散列”方法，该方法可以查找索引的第一行，其中前导索引列A为零：

Answer 2

假设您在 A、B、C 和 D 上有一个索引。也可以过滤。

这更有可能使用索引然后添加。

Where A=0 and B=0 and C=0 and D=0

在其他新闻中，如果 A 是 -1 而 B 是 1，A+B=0则为真但A=0 and B=0为假。

Answer 3

^{（请注意，此答案是在问题中注明的任何测试之前提交的：问题的文本在测试结果部分的正上方结束。）}

我猜想单独的AND条件将是首选，因为如果其中一个不等于 0，优化器更有可能使操作短路，而无需先进行计算。

尽管如此，由于这是一个性能问题，您应该首先设置一个测试以确定您的硬件的答案。报告这些结果，展示您的测试代码，并请其他人查看以确保它是一个良好的测试。可能还有其他您没有考虑过的值得考虑的因素。