初涉SQL Server性能问题(4/4):列出最耗资源的会话

简介:

这篇文章我们看下从计划缓存里列出执行状态。

复制代码
 1 /*****************************************************************************************
 2 List heavy query based on CPU/IO. Change the order by clause appropriately
 3 ******************************************************************************************/
 4 SELECT TOP 20
 5 DB_NAME(qt.dbid) AS DatabaseName
 6 ,DATEDIFF(MI,creation_time,GETDATE()) AS [Age of the Plan(Minutes)]
 7 ,last_execution_time AS [Last Execution Time]
 8 ,qs.execution_count AS [Total Execution Count]
 9 ,CAST((qs.total_elapsed_time) / 1000000.0 AS DECIMAL(28,2)) [Total Elapsed Time(s)]
10 ,CAST((qs.total_elapsed_time ) / 1000000.0/ qs.execution_count AS DECIMAL(28, 2)) AS [Average Execution time(s)]
11 ,CAST((qs.total_worker_time) / 1000000.0 AS DECIMAL(28,2)) AS [Total CPU time (s)]
12 ,CAST(qs.total_worker_time * 100.0 / qs.total_elapsed_time AS DECIMAL(28,2)) AS [% CPU]
13 ,CAST((qs.total_elapsed_time - qs.total_worker_time)* 100.0 /qs.total_elapsed_time AS DECIMAL(28, 2)) AS [% Waiting]
14 ,CAST((qs.total_worker_time) / 1000000.0/ qs.execution_count AS DECIMAL(28, 2)) AS [CPU time average (s)]
15 ,CAST((qs.total_physical_reads) / qs.execution_count AS DECIMAL(28, 2)) AS [Avg Physical Read]
16 ,CAST((qs.total_logical_reads) / qs.execution_count AS DECIMAL(28, 2))  AS [Avg Logical Reads]
17 ,CAST((qs.total_logical_writes) / qs.execution_count AS DECIMAL(28, 2)) AS [Avg Logical Writes]
18 ,max_physical_reads
19 ,max_logical_reads
20 ,max_logical_writes
21 , SUBSTRING (qt.TEXT,(qs.statement_start_offset/2) + 1,((CASE WHEN qs.statement_end_offset = -1
22    THEN LEN(CONVERT(NVARCHAR(MAX), qt.TEXT)) * 2
23    ELSE qs.statement_end_offset
24    END - qs.statement_start_offset)/2) + 1) AS [Individual Query]
25 , qt.TEXT AS [Batch Statement]
26 , qp.query_plan
27 FROM SYS.DM_EXEC_QUERY_STATS qs
28 CROSS APPLY SYS.DM_EXEC_SQL_TEXT(qs.sql_handle) AS qt
29 CROSS APPLY SYS.DM_EXEC_QUERY_PLAN(qs.plan_handle) qp
30 WHERE qs.total_elapsed_time > 0
31 ORDER BY 
32 [Total CPU time (s)] 
33 --[Avg Physical Read]
34 --[Avg Logical Reads]
35 --[Avg Logical Writes]
36 --[Total Elapsed Time(s)]
37 --[Total Execution Count]
38 DESC 
复制代码

输出结果的每列说明介绍如下:

  • DatabaseName 执行计划的数据库环境(数据库名)。
  • Age of the Plan(Minutes) 计划缓存里计划的生存期,单位为分钟。
  • Last Execution Time 这个计划的上次执行日期和时间。
  • Total Execution Count   自上次编译后,总执行次数;在执行计划生存期内[Age of the Plan(Minutes)],总执行次数(自上次编译后)。
  • Total Elapsed Time(s)   执行这个计划总执行次数后[Total Execution Count]的总占用时间,单位为秒。
  • Average Execution time(s) 这个计划每次执行的平均时间,单位为秒。
  • Total CPU time (s)  执行这个计划总执行次数后[Total Execution Count]的总CPU时间,单位为秒。
  • % CPU 与Total Elapsed Time(s)相比,CPU占用时间比。
  • % Waiting  与Total Elapsed Time(s)相比,等待资源占用时间比。
  • CPU time average (s) 每次执行的平均CPU时间,单位为秒。
  • Avg Physical Read 每次执行的平均物理读数。
  • Avg Logical Reads 每次执行的平均逻辑读数。
  • Avg Logical Writes 每次执行的平均逻辑写数。
  • max_physical_reads 每次执行的时候,出新最大物理读数。
  • max_logical_reads 每次执行的时候,出新最大逻辑读数。
  • max_logical_writes 每次执行的时候,出新最大逻辑写数。
  • Individual Query  批处理语句的部分信息。
  • Batch Statement  批处理查询。
  • query_plan XML格式的执行计划,点击后我们可以看图示执行计划。

一般我们可以分析前5条记录(通过修改排序规则)的具体语句信息。大多数情况,我们会发现问题出现在临时表的滥用,distinct语句,游标,不合适的表连接条件,不合适的索引等等。其他经常发生的问题是,存储过程对数据库的大量调用(CPU消耗和执行时间都很小)。这个需要和开发人员反馈,修改下具体的实现方式。如果数据经常被调用,可以在程序里使用缓存方法避免与服务器的多次交互。有些对数据库的调用只是检查结果数据是否有改变。有些对数据库的调用是为检查数据库表里是否有新记录,且必须马上处理的。为了完成这些操作,程序会在1秒内多次查询表来找出未处理的记录。这个可以通过程序的异步调用来往表里插入数据来解决,或可以使用.net框架里的sqlDependency来解决。(sqlDependency提供了这样一种能力:当被监测的数据库中的数据发生变化时,SqlDependency会自动触发OnChange事件来通知应用程序,从而达到让系统自动更新数据(或缓存)的目的。)


本文转自Woodytu博客园博客,原文链接:http://www.cnblogs.com/woodytu/p/4543913.html,如需转载请自行联系原作者

相关文章
|
3月前
|
SQL 关系型数据库 MySQL
为什么这些 SQL 语句逻辑相同,性能却差异巨大?
我是小假 期待与你的下一次相遇 ~
228 0
|
7月前
|
SQL 关系型数据库 PostgreSQL
CTE vs 子查询:深入拆解PostgreSQL复杂SQL的隐藏性能差异
本文深入探讨了PostgreSQL中CTE(公共表表达式)与子查询的选择对SQL性能的影响。通过分析两者底层机制,揭示CTE的物化特性及子查询的优化融合优势,并结合多场景案例对比执行效率。最终给出决策指南,帮助开发者根据数据量、引用次数和复杂度选择最优方案,同时提供高级优化技巧和版本演进建议,助力SQL性能调优。
758 1
|
SQL 存储 关系型数据库
如何巧用索引优化SQL语句性能?
本文从索引角度探讨了如何优化MySQL中的SQL语句性能。首先介绍了如何通过查看执行时间和执行计划定位慢SQL,并详细解析了EXPLAIN命令的各个字段含义。接着讲解了索引优化的关键点,包括聚簇索引、索引覆盖、联合索引及最左前缀原则等。最后,通过具体示例展示了索引如何提升查询速度,并提供了三层B+树的存储容量计算方法。通过这些技巧,可以帮助开发者有效提升数据库查询效率。
1136 2
|
10月前
|
SQL 关系型数据库 MySQL
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
|
11月前
|
SQL 关系型数据库 OLAP
云原生数据仓库AnalyticDB PostgreSQL同一个SQL可以实现向量索引、全文索引GIN、普通索引BTREE混合查询,简化业务实现逻辑、提升查询性能
本文档介绍了如何在AnalyticDB for PostgreSQL中创建表、向量索引及混合检索的实现步骤。主要内容包括:创建`articles`表并设置向量存储格式,创建ANN向量索引,为表增加`username`和`time`列,建立BTREE索引和GIN全文检索索引,并展示了查询结果。参考文档提供了详细的SQL语句和配置说明。
420 2
|
SQL Oracle 关系型数据库
如何在 Oracle 中配置和使用 SQL Profiles 来优化查询性能?
在 Oracle 数据库中,SQL Profiles 是优化查询性能的工具,通过提供额外统计信息帮助生成更有效的执行计划。配置和使用步骤包括:1. 启用自动 SQL 调优;2. 手动创建 SQL Profile,涉及收集、执行调优任务、查看报告及应用建议;3. 验证效果;4. 使用 `DBA_SQL_PROFILES` 视图管理 Profile。
|
SQL 存储 缓存
如何优化SQL查询性能?
【10月更文挑战第28天】如何优化SQL查询性能?
897 10
|
SQL 数据库 UED
SQL性能提升秘籍:5步优化法与10个实战案例
在数据库管理和应用开发中,SQL查询的性能优化至关重要。高效的SQL查询不仅可以提高应用的响应速度,还能降低服务器负载,提升用户体验。本文将分享SQL优化的五大步骤和十个实战案例,帮助构建高效、稳定的数据库应用。
1242 3
|
SQL IDE 数据库连接
IntelliJ IDEA处理大文件SQL:性能优势解析
在数据库开发和管理工作中,执行大型SQL文件是一个常见的任务。传统的数据库管理工具如Navicat在处理大型SQL文件时可能会遇到性能瓶颈。而IntelliJ IDEA,作为一个强大的集成开发环境,提供了一些高级功能,使其在执行大文件SQL时表现出色。本文将探讨IntelliJ IDEA在处理大文件SQL时的性能优势,并与Navicat进行比较。
276 4
|
SQL 关系型数据库 MySQL
惊呆:where 1=1 可能严重影响性能,差了10多倍,快去排查你的 sql
老架构师尼恩在读者交流群中分享了关于MySQL中“where 1=1”条件的性能影响及其解决方案。该条件在动态SQL中常用,但可能在无真实条件时导致全表扫描,严重影响性能。尼恩建议通过其他条件或SQL子句命中索引,或使用MyBatis的`<where>`标签来避免性能问题。他还提供了详细的执行计划分析和优化建议,帮助大家在面试中展示深厚的技术功底,赢得面试官的青睐。更多内容可参考《尼恩Java面试宝典PDF》。