我发现我最近花了很多时间检查由索引调整顾问或其他一些自动化过程生成的建议索引列表。
回到那天（大约 2005 年），我发现这些建议相当糟糕，因为它们似乎是针对一个特定查询的，而且通常只是一个包含表中每一列的覆盖索引，无论这些列是否已经是索引.
随着时间的推移，我觉得索引调整顾问有了很大的改进，但我仍然有一种内在的不信任，仍然想花时间去审查每一个。
我试图不悲观，但是当供应商（Microsoft）建议添加多个重叠覆盖索引以提高性能时，这很困难，尤其是当我们为存储空间付费时。我也不想浪费自己的时间。我宁愿修复写得不好的查询。
请记住，它只是一个顾问……就像在生活中一样，他们并不总是在您应该走的道路上。它是免费的建议采取或离开。
在大多数情况下，它基于 SQL Server 中的 DMV 数据，因此它甚至可以根据它认为的问题进行波动。我一般会将它们作为指南。
例子：
我看到一组显示“建议”索引的通用表。好吧，这会告诉我，也许当前索引，对于那些表，需要根据当前正在运行的负载进行审查。索引架构可以在应用程序的整个生命周期中发生变化，在 1.0 版发布期间创建的索引在达到 5.0 版后可能会有所不同。
然后我可能会使用sp_BlitzIndex或Jason Strate 的索引分析来查看表和索引。也许通过并捕获主机表的执行计划，或者从缓存中提取它们。
但请记住，如果可以的话，值得测试添加到表中的任何索引。如果没有，并且您正在修改索引，那么请确保为当前索引制作一个脚本，以便您可以恢复它们。
作为一名查看大量非 DBA 管理的服务器的顾问，我在 sp_BlitzIndex 的“Index Hoarder：Unused NC index”部分看到了很多 DTA索引。它们也经常出现在“多索引个性：重复键”或“多索引个性：边缘重复键”部分。有时正在使用这些索引，但它们的读取很少而写入很多。
我建议使用 sp_BlitzIndex 或替代的缺失索引脚本来查找数据库的高价值缺失索引，而不是使用 DTA。如果使用 sp_BlitzIndex，请考虑“估计每天收益”为 500 万或更高的索引。如果“使用”很高，我有时甚至会推荐 100 万或更多的产品。
对 DTA 可能不是，但对存储在执行计划中的缺失索引细节几乎肯定是肯定的。
我整天都看到低效的垃圾查询拖累服务器。我经常传递缺失索引列表以及执行计划，结果却听到供应商支支吾吾。“我们不能只是应用任何东西！”
因此，无论证据多么有力，他们都不会应用任何东西。测试和剖析并证明这一点——他们不在乎。
索引不需要手工制作，这里有一半索引在那里有一半索引通常是不够的 - 如果这会导致嵌套循环或在大表上重复进行键查找，那么这可能会导致问题。
缺少索引警告被触发是有充分理由的。显然，不值得在所有方面都创建所有这些，有些可能不会产生巨大的有益影响（而是产生有益但微不足道的影响）。
但在大多数情况下，按 CPU、IO 和计数分析的前几项结果证明是有益的。你更有可能拥有一个带有垃圾索引的垃圾执行计划，而不是神奇地偶然发现一个带有垃圾索引的更好的工作执行计划。
这不是数据科学。