我有一个存储过程，它通常运行得非常快(几乎没有几秒钟)，但是在奇数的日子里，具有相同参数的相同过程需要几分钟才能执行。但是如果我此时对索引进行碎片整理，它会在几秒钟内再次开始运行。
这可能是因为糟糕的执行计划或碎片化的索引吗？
如果是这样，有没有办法让这个过程不依赖于执行计划或碎片索引？
提前致谢，
约瑟夫
最佳答案
好吧，根据您的 SP，解决方案可能是通过以下选项:
1/WITH RECOMPILE 可以拯救你的一天。这通过重新编译 SP 增加了总执行时间，但它确保您将拥有最佳执行计划。
2/KEEPFIXED PLAN 也可以是一个选项。
3/值得尝试一下 OPTIMIZE FOR，以防您有一组从统计角度来看“具有代表性”的参数。
4/监控涉及的表和索引的碎片级别。检查是否存在大量更新 SP 使用的表的语句。如果是，则 update statistics ( UPDATE STATISTICS <tablename>; )
5/参数嗅探也可能是根本原因。
您可以进一步了解细节并查看 list of causes of recompilations 。
关于sql-server - 由于计划错误或索引碎片化，MS SQL 查询速度变慢，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/23362311/