我们有这个数据库应用程序，它不断运行具有不同参数的复杂查询。它是一个编译存储过程 (C#)，它调用 4 个普通存储过程，它们将 4 到 6 个表连接在一起，并且 C# 代码在调用之间合并结果。
这已经运行良好（快速）6 个月，直到数据库恢复。然后性能从几乎瞬间变为 20 多秒。谷歌搜索清楚地表明更新统计信息必须在表上运行，是的，它有效，再次即时查询。
但是一个月后问题又来了。好的，没问题，再次“更新统计信息”。又快了。然后花了一个星期才回来。出乎意料的慢查询。然后问题越来越快地再次出现，此时更新统计数据不再有帮助。
如何分析这类问题？关于性能方面的编译存储过程和查询计划有什么需要了解的吗？
我认为该表需要索引。在表上创建索引。使用 SQL Server Profiler 和另一个我不记得的工具来分析查询并告诉您是否需要索引优化/创建。
索引应该处理慢查询。此外，查询中还有其他需要查看的内容，例如几个表、主 ID 上的连接等。
你应该去“divide et impera”:)。
这 4 个正常的存储过程在编译后的 SP 之外是如何工作的？你能单独运行它们吗？他们每个人的执行计划看起来不错吗？您是否对它们中的每一个都使用索引？（正确使用索引应该转化为Index Seek执行计划中的操作，最好是Clustered Index Seek操作）
如果这些看起来不错，那么检查编译的存储过程。寻找任何可能的瓶颈，尤其是在连接大量数据时。
我个人也同意这可以通过适当的索引来解决。
当索引丢失时，SQL Server 会尝试根据统计信息优化代码的执行。统计信息可能与数据不同步，因此当它们不是最新的时，SQL Server 可能会低效地运行您的代码。
但是当您定义索引时，您基本上是在告诉 SQL Server 如何以最佳方式执行您的查询。
假设 MSSQL，在数据库属性下；选项，检查“自动更新统计”是否为真。如果将其设置为 False 将很少见，但这是有可能的。
性能调优应该分步进行，首先尝试根据表和表上现有的索引来调优查询。这可以通过适当的连接、避免通配符、联合等来完成，可以通过使用执行计划来完成。如果您已准备好查询，您可以检查在列上创建更多索引是否会提高查询性能。请记住，新索引可能会提高“SELECT”查询的性能，但会降低 UPDATE、INSERT、DELETE 的性能。