Rac*_*pta 3 sql-server statistics index-tuning amazon-rds query-performance
我有一个包含 17,093,139 行的大堆表。该表是数据库中使用最频繁的表。由于这是一个堆表，因此该表中只有非聚集索引。我定期重建/重组这个表上的碎片索引。
现在我们经常面临这个问题：访问此表的大量查询突然开始比平时花费更长的时间。当我检查时，我观察到查询的执行计划已更改。
我创建并删除了一个随机的非聚集索引，这解决了这个问题。
我不明白的是，是什么导致这些突然突然变慢的原因是什么，创建和删除索引在后台对表做了什么来修复它，而索引重建作业没有做？
我需要找出究竟是什么触发了这些减速，以便找到一个永久的解决方案，因为我不能只是每次都继续创建和删除索引来解决这个问题。
这里的任何帮助将不胜感激。
删除表上的索引将从缓存中刷新引用此表的执行计划。（我认为索引需要包含查询中引用的列，但不能 100% 确定）。
SQL 然后构建一个新的执行计划来“修复”您的问题。
您可以尝试重建统计信息（而不是删除索引），或手动删除执行计划（请参阅 Sp_blitz 存储过程以轻松获取命令）。您可能会有相同的行为（查询修复）。如果是这样，那么您可能需要阅读参数嗅探问题。
Ps 对于没有集群索引的表来说，这很少是一个好习惯。通常，我见过的唯一好的情况是对于日志表，您希望在其中快速完成插入......但在您的情况下，如果您有非聚集索引，无论如何您都会有插入的开销。