MySQL慢查询日志启用需同时满足slow_query_log=ON、slow_query_log_file有效且long_query_time设为合理值（如0.5），否则日志为空；需在my.cnf中持久化配置并用mysqldumpslow分析，结合EXPLAIN聚焦type/key/rows三列，优先构建覆盖索引优化。
如何确认 MySQL 慢查询日志是否真正启用
很多情况下你以为开启了慢查询日志，但 slow_query_log 变量显示 ON，实际日志文件却为空——根本原因是 long_query_time 设置过高（比如默认 10 秒），而你的业务里几乎没有执行超 10 秒的语句。
检查和修正步骤：
- 用
SHOW VARIABLES LIKE 'slow_query_log%';确认slow_query_log和slow_query_log_file的值 - 运行
SELECT @@long_query_time;，生产环境建议设为1.0或更低（注意：MySQL 5.7+ 支持毫秒级，如0.5） - 动态生效需执行
SET GLOBAL long_query_time = 0.5;（注意：该命令对已连接会话不生效） - 务必在
my.cnf中补全配置，避免重启后失效：[mysqld] slow_query_log = ON slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 0.5 log_queries_not_using_indexes = OFF
log_queries_not_using_indexes = ON 虽能暴露缺失索引的查询，但日志量爆炸，上线前务必关掉。
用 mysqldumpslow 快速定位高频/高耗时 SQL
mysqldumpslow 是 MySQL 自带的解析工具，比手动 grep 或写脚本更可靠——它能自动归一化 SQL（比如把 WHERE id = 123 和 WHERE id = 456 合并为 WHERE id = ?）。
常用组合命令：
- 按执行次数排序，看谁调用最频繁：
mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log - 按平均查询时间排序，找“单次最慢”的语句：
mysqldumpslow -s at -t 10 /var/log/mysql/mysql-slow.log - 只看扫描行数超过 1000 的：
mysqldumpslow -m 1000 -t 10 /var/log/mysql/mysql-slow.log
注意：-s at 是平均时间（average time），不是最大时间；-m 参数仅在 MySQL 8.0.22+ 支持，低版本需靠 awk 过滤 Rows_examined 字段。
EXPLAIN 结果里最关键的三列怎么看
拿到慢 SQL 后，不要急着加索引。先跑 EXPLAIN FORMAT=TRADITIONAL，盯住这三列：
-
type：必须至少到range，ALL或index表示全表/全索引扫描，危险信号 -
key：显示实际命中哪个索引。若为NULL，说明没走索引（可能因隐式类型转换、函数包裹字段、或OR条件破坏索引选择） -
rows：预估扫描行数。若远大于结果集行数（比如SELECT COUNT(*)返回 100 行，但rows=50000），说明索引区分度差或没覆盖查询条件
典型陷阱：ORDER BY 字段不在索引中，即使 WHERE 走了索引，也可能触发 Using filesort；GROUP BY 后跟 HAVING 且无对应索引，同样会导致临时表 + 排序。
优化时优先考虑覆盖索引而非单纯提速 WHERE
很多同学看到 WHERE a = ? AND b = ? 慢，就建 (a,b) 索引。但如果查询还带 SELECT c, d，而 c,d 不在索引里，MySQL 仍要回表查聚簇索引——IO 成本没省多少。
正确做法是构建覆盖索引：
ALTER TABLE orders ADD INDEX idx_user_status_created (user_id, status, created_at);
这样当执行 SELECT status, created_at FROM orders WHERE user_id = 123 时，Extra 字段会显示 Using index，全程只访问二级索引，不碰主键 B+ 树。
但注意：覆盖索引字段越多，索引体积越大，写入开销上升。别把所有 SELECT * 字段都塞进去；也别在 TEXT 或长 VARCHAR 列上建覆盖索引（会触发前缀索引截断，降低准确性）。