“警告：操作导致残留的I / O”与关键查找

我在SQL Server 2017执行计划中看到了以下警告：

警告：操作导致剩余IO [sic]。实际读取的行数为（3,321,318），但返回的行数为40。

这是SQLSentry PlanExplorer的片段：

为了改进代码，我添加了非聚集索引，因此SQL Server可以访问相关行。它工作正常，但通常索引中将包含太多（大）列。看起来像这样：

如果我仅添加索引，而没有包含列，则强制使用索引，如下所示：

显然，SQL Server认为密钥查找比剩余的I / O昂贵得多。我有一个没有大量测试数据的测试设置（但是），但是当代码投入生产时，它需要处理更多的数据，所以我很确定需要某种非聚集索引。

当您在SSD上运行时，关键查询真的那么昂贵吗？我必须创建全脂索引（包含很多包含列）吗？

执行计划： https : //www.brentozar.com/pastetheplan/?id=SJtiRte2X这是一个长存储过程的一部分。寻找IX_BatchNo_DeviceNo_CreatedUTC。

优化器使用的成本模型正好是：模型。在广泛的工作负载，广泛的数据库设计，广泛的硬件上，它通常会产生良好的结果。

通常，您不应假定单个成本估算将与特定硬件配置上的运行时性能密切相关。作业成本法的要点是允许优化器产生一个受过教育的候选物理的替代品之间的选择。同样的逻辑运算。

当您真正了解细节时，熟练的数据库专家（还有时间调优重要的查询）通常可以做得更好。在此程度上，您可以将优化器的计划选择视为一个良好的起点。在大多数情况下，该起点也将是终点，因为找到的解决方案足够好。

以我的经验（和观点），SQL Server查询优化器的查找成本比我希望的高。与当今相比，与顺序访问相比，随机物理I / O的价格要昂贵得多。

尽管如此，即使在SSD上，甚至在仅从内存中读取时，查找的代价仍然很高。遍历b树结构不是免费的。显然，随着您执行更多的操作，成本在增加。

包含的列非常适合读取大量OLTP工作负载，在索引空间使用和更新成本与运行时读取性能之间进行权衡是有意义的。还需要权衡计划的稳定性。完全覆盖的索引避免了优化器的成本模型何时可能从一个替代方案转换为另一个替代方案的问题。

只有您可以决定在您的情况下是否值得进行权衡。在代表性数据样本上测试这两种选择，并做出明智的选择。

在问题注释中，您添加了：

您是在告诉我SQL Server不知道剩余IO的成本吗？

不，优化程序会考虑剩余I / O的成本。实际上，就优化器而言，非SARG谓词在单独的过滤器中进行评估。在优化后的重写过程中，此过滤器会作为残差推入搜索或扫描。