我在一台服务器上有一个查询，优化器估计其成本为 0.01。实际上，它最终运行得非常糟糕。

• 它最终执行聚簇索引扫描

注意：您可以在 Stackoverflow 上找到详细的 ddl、sql、表等。但是这些信息虽然很有趣，但在这里并不重要——这是一个不相关的问题。而且这道题连DDL都不需要。

如果我强制使用覆盖索引查找，它估计使用该索引的子树成本为 0.04。

• 聚簇索引扫描：0.01
• 覆盖指数扫描：0.04

因此，服务器选择使用以下计划也就不足为奇了：

• 实际上导致聚集索引的 147,000 次逻辑读取
• 而不是更快的 16 次覆盖索引读取

服务器A：

| Plan                                       | Cost      | I/O Cost    | CPU Cost  |
|--------------------------------------------|-----------|-------------|-----------|
| clustered index scan (optimizer preferred) | 0.0106035 | 116.574     | 5.01949   | Actually run extraordinarily terrible (147k logical reads, 27 seconds)
| covering index seek (force hint)           | 0.048894  |   0.0305324 | 0.0183616 | actually runs very fast (16 logical reads, instant)

这与使用 FULLSCAN 更新的统计数据一样。

在另一台服务器上试试

所以我尝试在另一台服务器上。我得到了相同查询的估计值，其中包含生产数据库的最新副本，以及最新的统计信息（WITH FULLSCAN）。

• 这另一台服务器也是 SQL Server 2014
• 但它正确地意识到聚簇索引扫描是不好的
• 它自然更喜欢覆盖索引查找（因为成本低 5 个数量级！）

服务器乙：

| Plan                                      | Cost        | I/O Cost   | CPU Cost  |
|-------------------------------------------|-------------|------------|-----------|
| Clustered index scan (force hint)         | 115.661     |   110.889  | 4.77115   | Runs extraordinarily terrible as server A (147k logical reads, 27 seconds)
| Covering index seek (optimizer preferred) |   0.0032831 |   0.003125 | 0.0001581 | Runs fast (16 logical reads, near instant)

我不明白的是，为什么这两台服务器的数据库副本几乎相同，都具有最新的统计信息，而且都是 SQL Server 2014：

• 可以如此正确地运行查询
• 另一个摔死了

我知道这似乎是统计数据过时的经典案例。或缓存的执行计划，或参数嗅探。但是这些测试查询都是用 发出的OPTION(RECOMPILE)，例如：

SELECT MIN(RowNumber) FROM Transactions
WITH (index=[IX_Transactions_TransactionDate]) WHERE TransactionDate >= '20191002 04:00:00.000' OPTION(RECOMPILE)

仔细一看，好像“运营商”的估计是错误的

聚簇索引扫描是一件坏事。其中一台服务器知道这一点。这是一个非常昂贵的操作，扫描操作应该告诉我这一点。

如果我强制执行聚簇索引扫描，并查看两台服务器上的估计扫描操作，我会突然想到：

| Cost                | Server A    | Server B   |
|---------------------|-------------|------------|
| I/O Cost            | 116.573     | 110.889    |
| CPU Cost            |   5.01945   |   4.77155  |
| Total Operator Cost |   0.0106035 | 115.661    |
                        mistakenly  | avoids it
                          uses it   |

服务器A上的操作员成本太低了。

• I /O成本合理
• CPU成本合理
• 但总的来说，运营商的总体成本低了 4 个数量级。

这就解释了为什么它错误地选择了糟糕的执行计划；它的运营成本很低。服务器 B 正确地找出了它，并避免了聚簇索引扫描。

不是operator = cpu + io吗？

在几乎每个执行计划节点上，您都会将鼠标悬停在上面，在 dba、stackoverflow 和每个博客上执行计划的每个屏幕截图上，您都会看到：

operatorCost >= max(cpuCost, ioCost)

事实上它通常是：

operatorCost = cpuCost + ioCost

那么这是怎么回事？

什么可以解释服务器决定 115 + 5 的成本几乎为零，而是决定成本的 1/10000？

我知道 SQL Server 有选项可以调整应用于 CPU 和 I/O 操作的内部权重：

DBCC    TRACEON (3604);     -- Show DBCC output
DBCC    SETCPUWEIGHT(1E0);  -- Default CPU weight
DBCC    SETIOWEIGHT(0.6E0); -- I/O multiplier = 0.6
DBCC    SHOWWEIGHTS;        -- Show the settings

当您这样做时，运算符成本最终可能会低于 CPU+I/O 成本：

但是没有人玩过这些。有没有可能 SQL Server 有一些基于环境的自动权重调整，或者基于与磁盘子系统的一些通信？

如果服务器是虚拟机，使用虚拟 SCSI 磁盘，通过光纤链路连接到存储区域网络 (SAN)，它可能会决定可以忽略 CPU 和 I/O 成本吗？

除了它不能是此服务器中的永久环境之外，因为我发现的所有其他查询都表现正常：

 I/O:       0.0112613
 CPU:      +0.0001
           =0.0113613 (theoretical)
 Operator:  0.0113613 (actual)

什么可以解释服务器不占用：

I/O Cost + Cpu Cost = Operator Cost

在这个例子中正确吗？

SQL 服务器 2014 SP2。