0

我编写了一个 SQL Server 2008 R2 存储过程来执行协调，并且我有一个协调状态标志 (TINYINT)，它的值可以是 0（新）、1（已协调）或 2（异常）。

在此过程中，我使用 != 运算符选择所有未成功协调到临时表中的记录：

SELECT FIELDS
INTO #TEMP_TABLE
FROM PERMANENT_TABLE
WHERE RECONCILIATION_STATUS != 1

在与工作中的 DBA 交谈时，他认为将其重新编码为：

SELECT FIELDS
INTO #TEMP_TABLE
FROM PERMANENT_TABLE
WHERE RECONCILIATION_STATUS in (0, 2)

性能会更好，因为我们知道 RECONCILIATION_STATUS 字段的所有可能值是多少。我找不到任何文献支持这一点，想知道他是否真的正确？

4

2 回答 2

3

显而易见的解决方案是测试两者。

首先设置一个示例模式：

IF OBJECT_ID(N'dbo.T', 'U') IS NOT NULL DROP TABLE dbo.T;
CREATE TABLE dbo.T 
(
    ID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY,
    RECONCILIATION_STATUS TINYINT NOT NULL CHECK (RECONCILIATION_STATUS IN (0, 1, 2)),
    Filler CHAR(100) NULL
);

INSERT dbo.T (RECONCILIATION_STATUS)
SELECT  TOP (100000) FLOOR(RAND(CHECKSUM(NEWID())) * 3)
FROM    sys.all_objects a, sys.all_objects b;

然后在没有索引的情况下测试

SELECT  COUNT(Filler)
FROM    dbo.T
WHERE   RECONCILIATION_STATUS != 1;

SELECT  COUNT(Filler)
FROM    dbo.T
WHERE   RECONCILIATION_STATUS IN (0, 2);

每个人的计划是：

在此处输入图像描述

正如您所看到的，这里的差异可以忽略不计，没有索引，两个查询都需要聚集索引扫描。

由于可能的值如此之少，非聚集索引不太可能有任何用处，除非您将定期需要的所有列作为非键列包括在内，或者没有太多数据。在 100,000 个样本行上使用标准非聚集索引，构建如下：

CREATE NONCLUSTERED INDEX IX_T__RECONCILIATION_STATUS
    ON dbo.T (RECONCILIATION_STATUS);

执行计划与聚集索引扫描保持相同。

将其他列作为非键索引包含在内：

CREATE NONCLUSTERED INDEX IX_T__RECONCILIATION_STATUS
    ON dbo.T (RECONCILIATION_STATUS) INCLUDE (Filler);

计划!= 1变得相当复杂，虽然我不会过多强调它的重要性，但估计的成本是一样的：

在此处输入图像描述

但是，IO 统计数据表明，实际所需的读取几乎没有什么不同：

药片'。扫描计数 2，逻辑读取 935，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。

药片'。扫描计数 2，逻辑读取 934，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。

到目前为止，几乎没有什么区别，但这实际上取决于您的数据分布，以及您拥有的索引和约束。

有趣的是，如果您为测试创建一个临时表并在其上定义检查约束：

IF OBJECT_ID(N'tempdb..#T', 'U') IS NOT NULL DROP TABLE #T;
CREATE TABLE #T 
(
    ID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY,
    RECONCILIATION_STATUS TINYINT NOT NULL CHECK (RECONCILIATION_STATUS IN (0, 1, 2)),
    Filler CHAR(100) NULL
);

INSERT #T (RECONCILIATION_STATUS)
SELECT  TOP (100000) FLOOR(RAND(CHECKSUM(NEWID())) * 3)
FROM    sys.all_objects a, sys.all_objects b;

优化器实际上会重写这个查询：

SELECT  COUNT(Filler)
FROM    #T
WHERE   RECONCILIATION_STATUS != 1;

作为

SELECT  COUNT(Filler)
FROM    #T
WHERE   RECONCILIATION_STATUS = 0
OR      RECONCILIATION_STATUS = 2;

如本执行计划所示：

在此处输入图像描述

不过，我无法在永久表上复制此行为。尽管如此，这让我相信最好的选择是

WHERE   RECONCILIATION_STATUS IN (0, 2);

不仅在性能方面，尽管在大多数情况下它似乎是微不足道的或根本不是，但在可读性和未来对附加值的证明方面肯定是这样。

然而，没有比对自己的数据运行这些测试更好的方法来找出答案。这将使您更好地了解什么比我可以从一小部分数据样本集中得出的任何假设表现得更好。

于 2016-07-19T16:18:04.303 回答
1

Alex K 在评论中提到，使用该in子句需要对每个值进行两次比较，而 using!=只是一个。因此，从表面上看，这将使单一价值解决方案更具吸引力。

我会将其与过滤Reconciliation_Status列上的过滤索引结合起来WHERE Reconcilition_Status != 1。从长远来看，这可能最终会带来更多的性能提升。

要考虑的另一件事是代码的可维护性。如果将来有可能在此列中允许更多值，那么in如果未更新查询，则使用该解决方案可能会立即使结果无效（因为如果您添加3为新值，in (0,2)过滤器将排除具有 3 的行，while!= 1仍将返回假定的所需结果。

于 2016-07-19T15:12:09.297 回答