定位耗时 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），可能需额外配置其慢日志。
用 mysqldumpslow 快速归类分析
原始慢日志杂乱冗长，直接 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" 可过滤含特定关键词的模板，缩小范围。
结合 EXPLAIN 精准诊断执行计划
找到可疑 SQL 后，别急着改逻辑，先看 MySQL 实际怎么执行它：
对 SELECT 语句加 EXPLAIN FORMAT=TREE（8.0+）或 EXPLAIN（通用），重点关注：– type：是否用了 index/ range/ ref？全表扫描（ALL）要警惕
– key 和 possible_keys：是否命中索引？为何没选最优索引？
– rows：预估扫描行数是否远超实际返回行数？
– Extra：出现 Using filesort、Using temporary、Using join buffer 意味着有优化空间 对 UPDATE/DELETE 也适用：
EXPLAIN UPDATE ... 或先转成等价 SELECT 再 explain。
实时抓取正在运行的长事务和阻塞
有些 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 已安装）可一键查长时间未结束的查询。
