查询优化器会忽略碎片索引吗？

Question

场景：我有一个带有索引的繁重 OLTP 表。我在一天或更短的时间内看到了许多插入、更新和删除以及索引碎片。在索引构建的第一天，优化器使用索引，在第二天或第三天，优化器完全跳过它。这是完全相同的查询。

我脑子里的问题：为什么有些查询计划会跳过索引，因为创建索引是为了帮助优化这些计划？

这篇文章的问题：优化器是否可以跳过一个严重碎片化的索引，例如我们有10亿条记录并建立了一个索引，然后两个小时后，所有十亿条记录被删除，我们有5亿条新记录？

我开始认为向该表添加索引根本无济于事，因为表的性质（数据输入快，数据输出快），但只是想了解为什么有一天，优化器会在其计划中使用该指数，但第二天不会。

Answer 1

AFAIK 优化器不知道索引碎片。如果它选择扫描碎片索引的计划，这可能是一个问题。

不过，优化器知道分配的数据大小。如果索引页有很多空闲空间（可能是由于内部碎片），这会使索引不太可能被使用。50% 的空闲空间意味着要扫描的 IO 量是两倍。不过，对于随机访问来说，这在任何程度上都无关紧要。

不过，这并不是一个巨大的影响。它可能会解释你所看到的。

如果这个小的影响使查询计划翻转为不使用索引，那么在查询优化器的眼中，索引永远不会超级好。这可能暗示您可以改进它。

此外，优化器似乎对缓冲池中缓存了多少索引有所猜测。在 XML 执行计划中有一些参考。我没有这方面的详细知识。

我开始认为向该表添加索引根本无济于事

我不会走那么远。也许您只需要在正确的位置重建或删除 DML-create 序列？或者，这可能只是一个查询调优问题（提出一个包含实际执行计划的新问题）。