问为什么要创建和删除一个随机索引来解决这个性能问题？

EN

删除表上的索引将刷新从缓存中引用此表的执行计划。(我认为索引需要包含查询中引用的列，但不能100%肯定)。

然后，SQL构建一个新的执行计划，“修复”您的问题。

您可以尝试重新构建统计数据(而不是删除索引)，或者手动删除执行计划(请参阅Sp_blitz存储过程以轻松获得命令)。您可能会有相同的行为(查询修复)。如果是这样，那么您可能希望阅读有关参数嗅探的问题。

附注：这是很少有一个好的实践，有一个没有集群索引的表。通常，我看到的唯一好的情况是在日志表中，您希望很快完成插入.但是在您的情况下，如果您有非聚集索引，那么无论如何您都会为插入设置开销。

你可能看到的可能与参数嗅探有关-

1-也许您应该捕获缓慢的计划，并将其保存到以后的新计划中进行比较。

1. 尝试从缓存中刷新特定的计划，以防您知道您保存的计划比较慢的特定进程。
2. 如果新计划更快的话，那就省省吧。
3. 比较两个计划，看看如果看到不同的结果，参数值是什么。

在此基础上，你可以更进一步。但在此之前，最好能知道情况是否真的如此。