Mag*_*ier 5 sql-server sql-server-2008-r2 index-tuning
SELECT *不幸的是，我们的应用程序开发人员对我们的数据库系统运行了大量查询。
sys.dm_db_missing_index的缺失索引建议包含很多案例，表明为这些案例创建 100% 覆盖非聚集索引。例如，实际上有一个包含 3 个索引列的索引和建议的额外 25 个包含的列。带有建议的键列的其他索引已经就位，但随后需要查找。
我对此感到有些惊讶。然而，由于基础查询运行非常高的成本往往和建议的指数自带的约50％这也许是一个有趣的选择产生影响。
我知道支持这些查询不是最佳实践和糟糕的设计，但我怀疑这是否可以在足够的时间内改变，所以我想知道这些索引是否会有所帮助或产生更多的成本而不是收益？
是否有规则或我只需要尝试/错误后果？
SELECT *是最好的，但我被要求按原样优化它，并且由于 SQL Server 本身建议这样做，我认为无论如何都值得考虑。我做了一些没有/使用 100% 覆盖索引的测试。结果：
SELECT *：成本之前：0,026 之后：0,00329（使用新索引）= -88% 改进
UPDATE：之前：0,043333 之后：0,0533（使用 ix）= +20%
INSERT：之前：0,1133 之后：0,1233 (ix 未使用)=equal
DELETE: before: 0,645 after: 0,655 (ix used) =equal.
结论：它对选择的调整比减缓变化要多得多。为什么不申请？
缺少的索引建议是在优化器碰巧注意到它正在考虑的当前谓词集的精确匹配索引不存在于基对象时添加的机会性条目。
DMV 中记录的信息旨在为熟练的数据库调谐器的正常活动提供有用的输入；它不打算被解释为一个综合分析的结果。记录的数据是一组完整的键和所需的其他列，以及添加原因的简要说明（平等、不平等、包括）。
记录的“影响”也非常基本：根据优化器使用的成本模型，它是估计成本的差异。像往常一样，这需要以健康的怀疑态度对待，因为硬件的实际性能特征与优化器的模型相匹配的可能性很小，即使是模糊的。
另请注意，成本估算在很大程度上取决于基数（行数）、平均行大小和分布信息。如果这些与实际值不合理接近，则“成本”是一个更不可靠的指标。尽管如此，现在我们只有估计成本，这就是报告的数字。同样，SQL Server 只是尽力提供帮助；由查看信息的人来正确解释它。
基于估计成本的测试可能有助于及早评估需要改进的目标领域，但它们不能替代对您的环境中任何重要指标的实际测量。持续时间、CPU 使用率、物理读取、内存使用率……等等……的相对重要性在不同情况下会有所不同。
关键是衡量真正的问题在哪里，记录基线，进行改进，然后根据成本衡量和评估收益。
要进行比缺失索引功能提供的更全面的分析，您需要通过数据库引擎优化顾问运行具有代表性的工作负载。即使在那里，建议仍然需要由人来评估，并且遵循类似于上述基线评估变化测量协议的内容。
也就是说，并非所有最终决定都将基于性能比较。可能还有其他考虑，例如避免特别不方便的与查找相关的死锁。索引调整有时既是科学又是艺术。