定位 MySQL 慢 SQL 的核心是结合慢查询日志 + 性能分析工具，而不是只看“执行时间长”这一个表象。关键在于快速识别真实瓶颈：是索引缺失、扫描行数过多、锁等待，还是语句本身逻辑低效。
开启并确认慢查询日志已生效
先确保日志在记录——很多问题卡在这一步就停了。检查是否启用：
执行 SHOW VARIABLES LIKE 'slow_query_log';，返回 ON 才算开启 确认日志路径：SHOW VARIABLES LIKE 'slow_query_log_file'; 检查阈值（默认 10 秒）：SHOW VARIABLES LIKE 'long_query_time';，线上建议调为 1~2 秒 确保记录未使用索引的查询：SET GLOBAL log_queries_not_using_indexes = ON;（临时生效，可加到 my.cnf 持久化）用 mysqldumpslow 快速筛出高频/高耗时 SQL
直接翻日志文件效率低。用 MySQL 自带工具聚合分析：
mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log：按总执行时间排序，取前 10 条 mysqldumpslow -s c -t 10 /var/lib/mysql/slow.log：按出现次数排序，找高频慢语句 mysqldumpslow -g "SELECT.*FROM orders" /var/lib/mysql/slow.log：按关键词过滤（注意转义正则特殊字符）重点关注 Rows_examined（扫描行数）远大于 Rows_sent（返回行数） 的语句，大概率缺索引或条件没走索引。
用 EXPLAIN 精准诊断单条 SQL 执行计划
拿到可疑 SQL 后，在测试库或从库上执行 EXPLAIN FORMAT=TRADITIONAL [你的SQL]，重点看这几列：
type：尽量是 ref / eq_ref；出现 ALL 或 index 表示全表或全索引扫描 key：实际使用的索引名；NULL 表示没走索引 rows：预估扫描行数；比实际结果集大几十倍以上就要警惕 Extra：出现 Using filesort、Using temporary、Using join buffer 是性能红灯特别注意 WHERE 条件字段的顺序是否匹配联合索引最左前缀，以及是否因隐式类型转换（如字符串字段查数字）导致索引失效。
结合 Performance Schema 定位隐藏瓶颈
慢日志只能看到“结果”，有些问题得深入运行时状态：
查锁等待：SELECT * FROM performance_schema.data_lock_waits; 查最近 1 小时内最耗时的语句：SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 10; 查 IO 瓶颈：SELECT * FROM performance_schema.file_summary_by_instance ORDER BY SUM_NUMBER_OF_BYTES_READ DESC LIMIT 5;这些信息能帮你判断：是 SQL 本身烂，还是被其他事务锁住，或是磁盘读太慢拖累了响应。
