定位慢SQL需先通过慢日志抓取问题SQL，再用EXPLAIN分析执行计划，结合EXPLAIN ANALYZE或profiling验证真实耗时，最后针对性优化索引与查询写法。
定位慢SQL，核心是“先找出来，再看为什么慢”。关键不在于一上来就调优，而是快速锁定问题SQL、确认执行瓶颈、验证优化效果。整个过程围绕日志采集、条件筛选、执行计划分析、针对性优化四步展开。
从数据库慢日志抓出“真凶”
MySQL默认的slow_query_log是第一道入口。确保它已开启，并合理设置阈值（如long_query_time = 1），避免日志爆炸或漏掉真实慢查询。
常见操作：
- 查日志路径：SHOW VARIABLES LIKE 'slow_query_log_file';
- 实时追加查看（Linux）：tail -f /var/lib/mysql/xxx-slow.log
- 用mysqldumpslow汇总分析，例如：mysqldumpslow -s t -t 10 /var/lib/mysql/xxx-slow.log（按总耗时排序，取前10条）
- 注意：日志中可能含重复参数（如? ?），需结合应用层日志或general_log补全实际值
用EXPLAIN看懂SQL到底卡在哪
拿到可疑SQL后，别急着改，先加EXPLAIN FORMAT=TRADITIONAL（或FORMAT=JSON）看执行计划。重点关注几项：
- type：是否用到高效访问类型（const、ref、range）？出现ALL说明全表扫描，大概率缺索引
- key和key_len：实际命中哪个索引？长度是否合理？比如联合索引(a,b,c)，只用WHERE a=1，key_len应为a字段长度；若用WHERE b=1则key为空，索引失效
- rows：预估扫描行数。远大于结果集行数（可用SELECT COUNT(*)对比），说明过滤效率低
- Extra：警惕Using filesort（排序未走索引）、Using temporary（临时表）、Using join buffer（关联缓存不足）等提示
结合实际数据验证执行计划是否“靠谱”
EXPLAIN只是预估，真实执行可能因数据分布、统计信息过期、并发锁等原因偏差很大。务必用EXPLAIN ANALYZE（MySQL 8.0.18+）或手动加SELECT SQL_NO_CACHE ...并开profiling测真实耗时。
更直接的办法：
- 在测试库还原相同数据量，执行SET profiling = 1;，再运行SQL，然后SHOW PROFILES;和SHOW PROFILE FOR QUERY N;看各阶段耗时（如Sending data、Sorting result）
- 观察SHOW ENGINE INNODB STATUS\G中的TRANSACTIONS部分，确认是否存在锁等待
- 用pt-query-digest分析慢日志，自动聚合、排序、标注异常指标（如高Rows_examined/Rows_sent比）
针对性优化，避开常见坑
优化不是盲目加索引，而是匹配查询模式。几个实用方向：
- 单列查询优先考虑覆盖索引：例如SELECT name FROM user WHERE status=1，可建INDEX(status, name)，避免回表
- ORDER BY + LIMIT 场景，确保排序字段在索引最右（如WHERE a=1 ORDER BY b LIMIT 10，索引设为(a,b)）
- 避免在WHERE中对字段做函数操作：WHERE YEAR(create_time) = 2023无法走索引，改用WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'
- 大表分页慎用OFFSET：改用“游标分页”，如WHERE id > last_seen_id ORDER BY id LIMIT 20
