慢查询日志是定位性能瓶颈的首要依据，而非直接优化SQL；需先确认日志真实启用（检查slow_query_log=ON、long_query_time生效、log_output与权限），再区分“慢SQL”与“被拖慢SQL”，结合系统状态（IO、锁、连接数、缓冲池命中率）综合判断根因。
直接看慢查询日志，别先跑 EXPLAIN 或改索引——90% 的“慢”，根本不是某条 SQL 本身写得差，而是它被卡在连接、锁、IO 或参数配置上。
确认慢查询日志是否真在记录
很多人以为开了 slow_query_log = ON 就万事大吉，结果翻了一周日志全是空的。常见原因有三个：
-
long_query_time设置了但没生效：MySQL 对已建立的连接不重载该值，必须新建连接才用新阈值； -
log_output = TABLE时，慢 SQL 写进mysql.slow_log表，不是文件——查日志得SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10，不是tail -f； -
slow_query_log_file路径目录 MySQL 进程无写权限，尤其 Docker 或非标准部署时，ls -ld /var/lib/mysql/data/看属主和权限。
快速验证是否在记录：执行一条明显慢的语句，比如 SELECT SLEEP(2)，再立刻查 mysql.slow_log 或对应日志文件，有记录才算真正启用。
区分“慢 SQL”和“被拖慢的 SQL”
日志里出现的 SQL，未必是元凶。典型场景是：
- 一条大事务 UPDATE 占着行锁，导致后续几十条 SELECT 全部排队等待，它们在慢日志里都显示耗时高，但
EXPLAIN看起来完全正常； -
SHOW GLOBAL STATUS LIKE 'Threads_running'持续 > 50，而SHOW PROCESSLIST里一堆State: Sending data或Locked，说明瓶颈不在单条语句逻辑，而在并发或锁资源； - 磁盘 IO 利用率 95%+（
iostat -x 1），此时哪怕加了完美索引，查询也照样卡——因为数据页根本读不进来。
所以看到慢 SQL 后，先别优化它，先跑这三句：SHOW ENGINE INNODB STATUS\G（看最近死锁和锁等待）、SELECT * FROM information_schema.INNODB_TRX（看长事务）、SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%'（看缓存命中率是否低于 95%）。
用 EXPLAIN 看执行计划时，盯死三个字段
EXPLAIN 不是用来“确认有没有索引”的，是用来验证“为什么没走你认为它该走的那个索引”。重点关注：
-
type：出现ALL或index必须处理；range是分水岭，ref及以上通常安全； -
key：显示的是实际选用的索引名，不是“可能用的”，如果和你预想的不一致，大概率是索引列顺序、类型隐式转换（比如varchar字段传整数）、或OR条件破坏了索引合并； -
Extra：含Using filesort或Using temporary是硬伤，说明排序或分组没走索引，即使rows很小，数据量一上去就崩。
注意：8.0 默认开启 optimizer_switch='use_index_extensions=on'，有时会让联合索引的覆盖行为变复杂，测试时可临时关掉对比效果。
线上环境别只信 long_query_time
long_query_time = 1 在业务高峰期可能漏掉关键问题。比如一个接口平均响应 800ms，但偶发卡到 3s，这时它不会进慢日志——因为 3s 是总链路耗时，数据库只贡献了其中 400ms，没超 1 秒。
更务实的做法是：
- 把
log_queries_not_using_indexes = ON打开，抓出所有全表扫描语句，哪怕它现在只要 50ms； - 配合应用层埋点，在 DAO 层记录每条 SQL 的实际执行时间（如 MyBatis 的
StatementHandler拦截），比数据库日志更贴近真实体验； - 用
pt-query-digest分析慢日志时，加--filter '$event->{Time} > 500'参数，单独挑出 500ms 以上的语句做聚合分析，比默认的 1s 更敏感。
真正的瓶颈往往藏在“不慢但高频”或“不慢但锁重”的 SQL 里，而不是日志顶部那几条显眼的“慢 SQL”。
