我有一个有17093139行的大堆表格。此表是数据库中使用率最高的表。由于这是一个堆表,因此该表中只有非聚集索引。我定期在这个表上重新构建/重新组织碎片索引。这些天,我们经常面临一个问题:
很多访问这个表的查询会突然开始花费比平时更长的时间。当我检查时,我观察到查询的执行计划已经更改。我创建并删除了一个随机的非聚集索引,这就解决了这个问题。我不明白的是,是什么导致了这些突如其来的速度突然变慢,以及在后台创建和删除索引对表做了什么来修复它,而索引重建作业并没有做到这一点。我需要找出到底是什么触发了这些减速,这样才能找到永久的解决方案,因为我不能每次都只是简单地创建和删除索引来解决这个问题。这里的任何帮助都将不胜感激。
发布于 2020-05-15 15:48:15
我会先试着找出您所说的查询计划中发生了什么变化,然后再试着理解为什么会发生变化。可能是并行性,也可能是由于使用的参数导致选择了不正确的查询计划。您可以找到查询计划,并将它们全部删除,这样就不会使用旧的查询计划。如果您发现总是生成新的查询计划,请查看参数嗅探。如果索引总是碎片化,为什么呢?如果您对主键使用GUID,这肯定会增加表中的碎片。我总是尝试使用整数作为主键。希望这能对你的调试有所帮助。祝你好运:)
发布于 2020-05-15 15:49:23
这听起来像是您正在遭受Index Fragmentation的痛苦,它在您插入或更新表中的数据时出现。这篇文章建议了Fixing Index Fragmentation的方法。
希望这能有所帮助。
https://stackoverflow.com/questions/61823009
复制相似问题