[mssql] 分析SQL Server中执行效率较低的SQL语句

查询性能分析较低的SQL语句

sql 复制代码
-- 查询性能分析
SELECT TOP 50
    qs.creation_time AS [编译时间],
    qs.last_execution_time AS [最后执行时间],
    qs.execution_count AS [执行次数],
    qs.total_worker_time/1000 AS [CPU总时间(ms)],
    qs.total_elapsed_time/1000 AS [总耗时(ms)],
    (qs.total_elapsed_time/qs.execution_count)/1000 AS [平均耗时(ms)],
    qs.total_logical_reads/qs.execution_count AS [平均逻辑读],
    qs.total_physical_reads/qs.execution_count AS [平均物理读],
    qp.query_plan AS [执行计划],
    CASE 
        WHEN qs.total_elapsed_time/qs.execution_count > 1000 THEN '严重'
        WHEN qs.total_elapsed_time/qs.execution_count > 500 THEN '警告'
        ELSE '正常'
    END AS [性能评级],
    SUBSTRING(st.text, 
        (qs.statement_start_offset/2) + 1,
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset 
         END - qs.statement_start_offset)/2) + 1
    ) AS [执行语句]
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE 
    qs.last_execution_time > DATEADD(HOUR, -24, GETDATE())
    AND st.text NOT LIKE '%sp_%'
    AND st.text NOT LIKE '%FETCH%'
ORDER BY 
    [平均耗时(ms)] DESC,
    [执行次数] DESC;

查看 SQL 执行计划

sql 复制代码
SET SHOWPLAN_XML ON;
GO
-- SQL语句
GO
SET SHOWPLAN_XML OFF;
GO

执行计划关键解读点:

‌索引使用‌

  • ✅ Index Seek:高效索引查找
  • ⚠️ Index Scan:可能需优化索引
  • ❌ Table Scan:全表扫描警告

‌连接类型‌

  • Nested Loops:小数据集适用
  • Hash Match:大数据连接内存消耗高
  • Merge Join:需排序预处理

‌警告标识‌

  • 红色惊叹号:缺失索引/统计信息过期
  • 高成本百分比:性能瓶颈节点

💡 优化建议:对出现 Key Lookup 的操作创建覆盖索引(INCLUDE 列)

相关推荐
Raymond运维4 小时前
MariaDB源码编译安装(二)
运维·数据库·mariadb
沢田纲吉4 小时前
🗄️ MySQL 表操作全面指南
数据库·后端·mysql
RestCloud20 小时前
SQL Server到Hive:批处理ETL性能提升30%的实战经验
数据库·api
RestCloud20 小时前
为什么说零代码 ETL 是未来趋势?
数据库·api
ClouGence1 天前
CloudCanal + Paimon + SelectDB 从 0 到 1 构建实时湖仓
数据库
DemonAvenger1 天前
NoSQL与MySQL混合架构设计:从入门到实战的最佳实践
数据库·mysql·性能优化
AAA修煤气灶刘哥2 天前
后端人速藏!数据库PD建模避坑指南
数据库·后端·mysql
RestCloud2 天前
揭秘 CDC 技术:让数据库同步快人一步
数据库·api
得物技术2 天前
MySQL单表为何别超2000万行?揭秘B+树与16KB页的生死博弈|得物技术
数据库·后端·mysql