【译】SQL性能优化:关于查找慢查询的几种方法分享转载
这是一篇老文,关于五种查找SQL慢查询的方法,以便开发人员可以在SQL Server中查找SQL慢查询并进行性能调优。
1. 使用 SQL DMV 查找慢查询
SQL Server 的一大特色是其内置的动态管理视图(DMV)。里面有大量的关于各种主题的信息。
有几个 DMV 提供有关查询统计信息、执行计划、最近查询等的数据,这些一起使用有奇效。
例如,下面的这个查询可用于查找使用最多读取、写入、工作时间 (CPU) 等的查询。
SELECT TOP 10 SUBSTRING(qt.TEXT, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.TEXT)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.total_logical_writes, qs.last_logical_writes,
qs.total_worker_time,
qs.last_worker_time,
qs.total_elapsed_time/1000000 total_elapsed_time_in_S,
qs.last_elapsed_time/1000000 last_elapsed_time_in_S,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_logical_reads DESC -- logical reads
-- ORDER BY qs.total_logical_writes DESC -- logical writes
-- ORDER BY qs.total_worker_time DESC -- CPU time
查询的结果如下,结果来自己制作的一款营销应用。
你可以看到一个特定的查询(前一个查询)占用了所有资源。
通过查看这个,我可以复制那个 SQL 查询,看看是否有一些方法可以改进它,比如添加索引等。
优点:始终可用的基本汇总统计信息。
缺点:不告诉你是什么在调用查询。随着时间的推移调用查询时无法可视化。
2. 通过 APM 解决方案查询报告
许多应用程序性能管理(APM) 工具的一大特色是它们能够跟踪 SQL 查询。例如,Retrace可以跨多个数据库提供程序(包括 SQL Server)跟踪 SQL 查询。而且可以告诉您查询已执行了多少次、平均需要多长时间以及哪些事务正在调用它,这对于 SQL 性能调优来说非常有用。
APM 解决方案通过在运行时对您的应用程序代码进行轻量级性能分析来收集这些数据。
下面是 Retrace 应用程序仪表板的屏幕截图,显示了特定应用程序的 SQL 查询耗时最长。
Retrace 收集有关正在执行的每个 SQL 查询的性能统计信息。您可以搜索特定查询以查找潜在问题。
通过选择单个查询,您可以查看该查询在一段时间内被调用的频率以及需要多长时间。您还可以查看哪些网页使用 SQL 查询以及它们的性能如何受到它的影响。
由于Retrace是一个轻量级的代码分析器并获取了ASP.NET请求跟踪,它甚至可以向您展示您的代码正在做什么。
下面是一个获取的跟踪,显示了所有的SQL查询以及有关代码正在做什么的细节。Retrace甚至可以在同一视图中显示日志消息。另外请注意,它显示了正在执行查询的服务器地址和数据库名称。您还可以看到返回了多少记录。
3. SQL Server Profiler(已弃用!)
SQL Server Profiler已经存在了很长时间。如果你尝试实时查看针对数据库执行的SQL查询,那么这是非常有用的。
注意:Microsoft 已宣布不推荐使用 SQL Server Profiler!
SQL Profiler 捕获有关您与 SQL Server 交互的非常详细的事件:
- 登录连接、断开连接和失败。
- SELECT、INSERT、UPDATE 和 DELETE 语句。
- RPC 批处理状态调用。
- 存储过程的开始和结束。
- 存储过程中语句的开始和结束。
- SQL 批处理的开始和结束。
- 写入 SQL Server 错误日志的错误。
- 在数据库对象上获取或释放的锁。
- 打开的光标。
- 安全权限检查。
优点:非常详细的数据可用。
缺点:您必须手动打开它。这会迫使您重新创建您试图捕捉的场景。它最终会消失,取而代之的是扩展事件。
4. SQL Server 扩展事件
SQL Profiler 已被SQL Server Extended Events取代。这肯定会激怒很多人,但我可以理解微软为什么这样做。
扩展事件通过事件跟踪 (ETW) 工作。这是所有 Microsoft 相关技术公开诊断数据的常用方法。
ETW 提供了更多的灵活性。作为开发人员,我可以轻松利用 SQL Server 中的 ETW 事件来收集数据以供自定义使用。这真的很酷,也很强大。
优点:更容易启用和保持运行。更容易开发自定义解决方案。
缺点:由于它是相当新的,大多数人可能没有意识到它。
5. SQL Azure 查询性能洞察
我将假设 SQL Azure 的性能报告是建立在扩展事件之上的。在 Azure 门户中,您可以访问非常有用的各种性能报告和优化技巧。
注意:这些报告功能仅适用于托管在 SQL Azure 上的数据库。
在下面的屏幕截图中,您可以看到 SQL Azure 如何让您轻松使用使用最多 CPU、数据 IO 和日志 IO 的查询。它内置了一些很棒的基本报告。
您还可以选择单个查询并获取更多详细信息以帮助进行 SQL 性能调整。
优点:基础报告很赞。
缺点:但仅适用于 Azure。没有跨多个数据库的报告。
总结
下次您需要对 SQL Server 进行一些性能调优,你可以尝试以上某一条,当然也可以结合,但是这毕竟是一篇老文,很多问题其实已经有了更好的策略。
PS:如果使用像Retrace这样的 APM 解决方案,请务必检查它内置了哪种 SQL 性能功能,这样能避开坑。
原文作者:Matt Watson