如何分析慢查询？

Question

我们有这个db应用程序，它不断运行具有不同参数的复杂查询。 它是一个编译的存储过程（C＃），它调用4个正常的存储过程，它们将4到6个表连接在一起，C＃代码在调用之间合并结果。

在数据库恢复之前，这已经运行了6个月。然后性能从几乎瞬间变为20+秒。谷歌搜索表明，必须在表格上运行更新统计数据，是否有效，即时查询。

然后问题在一个月后又回来了。没问题，再次“更新统计数据”。又快了。然后花了一个星期才回来。缓慢的查询突然出现。然后问题就越来越快地恢复，此时更新统计数据已经没有任何帮助了。

如何分析这类问题？在性能方面是否有关于编译存储过程和查询计划的知识？

Answer 1

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

索引应该处理慢查询。此外，查询中还应该查看其他内容，例如几个表，主要ID上的连接等。

Answer 2

你应该去“除了et impera”:)。

这4个正常存储过程如何在编译的SP之外进行？你可以单独运行它们吗？每个执行计划看起来都很好吗？你在为每个人使用索引吗？ （正确使用索引应转换为执行计划中的Index Seek操作，理想情况下Clustered Index Seek操作）

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

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

当缺少索引时，SQL Server正在尝试根据统计信息优化代码的执行。统计信息可能与数据不同步，因此当它们不是最新的时，SQL Server可能无法有效地运行您的代码。

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

Answer 3

假设MSSQL，在Database Properties下;选项，检查“自动更新统计信息”是否为True。如果将其设置为False，则很少见，但这是可能的。

Answer 4

应该逐步处理性能调优，首先尝试根据Table和表上的现有索引来调优查询。这可以通过适当的连接，避免通配符，联合等等来完成，可以通过使用执行计划来完成。如果您已准备好查询，则可以检查在列上创建更多索引是否会提高查询性能。请记住，新索引可能会提高“SELECT”查询的性能，但会降低UPDATE，INSERT，DELETE的性能。