如何定位耗时sql_mysql性能分析技巧_网络技术_宿州市腾雀网络科技有限公司

发布时间 - 2026-02-03 00:00:00 点击率：次

定位耗时SQL需先启用慢查询日志并配置long_query_time，再用mysqldumpslow归类分析，接着通过EXPLAIN诊断执行计划，最后结合PROCESSLIST和锁等待监控长事务与阻塞。

定位耗时 SQL 是 MySQL 性能分析中最直接也最关键的一步。核心思路是：先抓“慢”的，再看“为什么慢”。重点不在查所有 SQL，而在快速聚焦真正拖慢系统的那几条。

这是最基础、最可靠的入口。MySQL 默认不记录慢查询，需手动启用：

在 my.cnf（或 my.ini）中添加：
slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1.0（单位秒，建议初设为 1，高并发场景可调至 0.5）
动态开启（无需重启）：
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
注意：long_query_time 对已建立连接不生效，新连接才生效；若用代理（如 ProxySQL），可能需额外配置其慢日志。

原始慢日志杂乱冗长，直接 grep 效率低。mysqldumpslow 是官方配套工具，能按模板聚合统计：

查看执行次数最多、平均耗时最长的前 10 条：
mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log
查看总耗时最长的前 10 条（关注“拖累大盘”的 SQL）：
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log
加 -g "WHERE.*status" 可过滤含特定关键词的模板，缩小范围。

找到可疑 SQL 后，别急着改逻辑，先看 MySQL 实际怎么执行它：

有些 SQL 并不慢，但因锁等待或事务过长，导致其他请求排队——这时慢日志可能不记录，需主动监控：

查当前运行超 1 秒的连接：
SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 1 AND COMMAND != 'Sleep';
查锁等待关系（8.0+）：
SELECT * FROM performance_schema.data_lock_waits;
或经典方式：
SHOW ENGINE INNODB STATUS\G，关注 TRANSACTIONS 部分的 lock wait。
配合 sys.schema_long_running_queries 视图（需 sys schema 已安装）可一键查长时间未结束的查询。