如何分析慢查询？

Question

我们有这个db应用程序，它用不同的参数连续运行一个复杂的查询。它是一个编译存储过程( C# )，它调用4个将4到6个表连接在一起的普通存储过程，C#代码在两次调用之间合并结果。

在恢复数据库之前，它已经正常(快速)运行了6个月。然后，性能从几乎瞬间变成了20+秒。谷歌它清楚地表明，update statistics必须在表上运行，是的，它工作了，再次即时查询。

但一个月后问题又回来了。好的，没问题，再次“更新统计数据”。又快了。然后花了一周的时间才回来。查询速度突然变慢。然后问题越来越快地卷土重来，在这一点上，更新统计数据根本没有任何帮助。

如何分析这类问题？关于编译的存储过程和查询计划在性能方面有什么需要了解的吗？

Answer 1

我认为这个表需要索引。在表上创建索引。使用SQL Server Profiler和另一个我记不清的工具来分析查询，并告诉您是否需要优化/创建索引。

索引应该处理慢查询。此外，查询中还有一些其他的东西需要考虑，比如几个表、主ids上的连接等。

Answer 2

你应该去"divide et impera“:)。

在编译后的SP之外，这4个普通存储过程做得如何？你能单独运行它们吗？他们每个人的执行计划看起来都很好吗？你对每一个都使用索引了吗？(正确使用索引应该转换为执行计划中的Index Seek操作，理想情况下是Clustered Index Seek操作)

如果这些看起来不错，那么请检查已编译的存储过程。寻找任何可能的瓶颈，特别是在连接大量数据时。

就我个人而言，我也同意这可以通过适当的索引来解决。

当索引丢失时，SQL Server会尝试根据统计信息优化代码的执行。统计信息可能会与数据不同步，因此当它们不是最新的时候，SQL Server可能会低效地运行您的代码。

但是当您定义索引时，您基本上是在告诉SQL Server如何以最佳方式执行查询。

Answer 3

假设MSSQL在“数据库属性；选项”下，检查“自动更新统计信息”是否为True。如果它被设置为False，这是很少见的，但这是一种可能性。