dat*_*god 1 sql-server index-tuning
我发现我最近花了很多时间检查由索引调整顾问或其他一些自动化过程生成的建议索引列表。
回到那天(大约 2005 年),我发现这些建议相当糟糕,因为它们似乎针对一个特定的查询,而且通常只是一个覆盖索引,该索引包含表中的每一列,无论这些列是否已经是索引.
随着时间的推移,我觉得指数调优顾问有了很大的进步,但我仍然有一种内在的不信任感,仍然想花时间对每一个进行审查。
我尽量不悲观,但是当供应商(Microsoft)建议添加多个重叠覆盖索引以提高性能时,这很困难,尤其是当我们为存储空间付费时。我也不想不必要地浪费自己的时间。我宁愿修复写得不好的查询。
小智 7
请记住,它只是一个顾问……就像在生活中,他们并不总是走在您应该走的道路上。接受或离开是免费的建议。
在大多数情况下,它基于 SQL Server 中的 DMV 数据,因此它甚至可以根据它认为的问题而波动。我一般会以他们为指导。
例子:
我看到一组常见的表显示“建议的”索引。那么这会告诉我,也许需要针对正在运行的当前负载检查这些表的当前索引。索引架构可以在应用程序的整个生命周期内发生变化,在发布版本 1.0 期间创建的索引可能会在您到达 5.0 版本时有所不同。
然后我可能会使用sp_BlitzIndex或Jason Strate的索引分析来查看表和索引。也许遍历并捕获 thost 表的执行计划,或者从缓存中提取它们。
但请记住,如果可以的话,测试您添加到表中的任何索引都是值得的。如果没有,并且您正在修改索引,那么请确保为当前索引制作脚本,以便您可以恢复它们。
| 归档时间: |
|
| 查看次数: |
468 次 |
| 最近记录: |