需确认慢查询日志是否真实记录目标sql：先检查slow_query_log是否开启及long_query_time是否设得过低（如0.1~0.5秒），再验证log_queries_not_using_indexes=on、日志路径可写，并用show variables确认运行时参数；接着从日志中筛选rows_examined远大于rows_sent且高频执行的语句，结合explain分析执行计划，警惕隐式类型转换；建索引前须评估区分度、复合索引顺序及是否已覆盖；上线后执行analyze table并用pt-query-digest对比优化效果，同时监控缓冲池i/o与索引维护成本。
怎么确认慢查询日志真在记录你关心的 SQL
默认 MySQL 不开启慢查询日志，即使开了也可能因 long_query_time 设置过高而漏掉实际有优化空间的语句。比如设成 2 秒，但某条 SELECT 在高峰期耗时 1.8 秒且频繁执行，它不会进日志，却可能拖垮整体响应。
实操建议：
- 在测试或预发环境将
long_query_time临时调低到0.1或0.5，观察真实负载下的慢 SQL 分布 - 务必开启
log_queries_not_using_indexes = ON，否则全表扫描的低效查询可能完全隐身 - 检查日志路径是否可写：
slow_query_log_file对应的目录需有 MySQL 进程的写权限，否则日志静默失效 - 用
SHOW VARIABLES LIKE 'slow_query_log%';和SHOW VARIABLES LIKE 'long_query_time';确认运行时值，别只看配置文件
从慢日志里快速定位「能加索引」的候选语句
日志里每条记录包含时间、锁等待、扫描行数（Rows_examined）、返回行数（Rows_sent）等关键字段。真正值得建索引的，不是“最慢”的那条，而是 Rows_examined 远大于 Rows_sent 且 WHERE 条件固定、频率高的语句。
实操建议：
- 用
mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log按平均耗时排序，但更要关注-s c（调用次数）和-s r（返回行数）组合筛选 - 对出现频次高、
Rows_examined> 10000 的语句，用EXPLAIN复现执行计划，重点看type是否为ALL或index，key是否为NULL - 警惕隐式类型转换：比如
WHERE user_id = '123'（字段是INT），会导致索引失效，日志里查不到对应索引使用痕迹
建索引前必须验证的三个条件
不是所有 WHERE 字段都适合单独建索引。盲目添加反而增加写入开销、占用内存，甚至让优化器选错执行路径。
实操建议：
- 单列索引优先考虑区分度：用
SELECT COUNT(DISTINCT column_name)/COUNT(*) FROM table_name;计算，结果接近 1 才值得独立建索引（如user_id），接近 0 则无效（如status只有 0/1） - 复合索引顺序必须匹配查询模式：若常查
WHERE a = ? AND b = ? ORDER BY c，则索引应为(a, b, c)，而非(a, c, b)—— 后者无法利用c做排序 - 检查是否已有覆盖索引：用
EXPLAIN FORMAT=JSON查看using_index是否为true，如果已是覆盖查询，加索引收益极小
上线后如何验证索引真的生效了
建完索引不代表问题消失。MySQL 可能因统计信息过期、数据倾斜或优化器误判，继续走全表扫描；也可能新索引被其他高频查询拖慢写入性能。
实操建议：
- 建索引后立刻执行
ANALYZE TABLE table_name;，强制更新统计信息，避免优化器沿用旧判断 - 在业务低峰用
pt-query-digest对比建索引前后同一批慢日志，重点关注Rows_examined是否下降、Query_time是否收敛 - 监控
Innodb_buffer_pool_reads和Innodb_buffer_pool_read_requests比值，若下降明显，说明索引减少了物理 I/O
容易被忽略的是索引维护成本：高频 INSERT/UPDATE 表上加索引，可能让单条写入变慢 20% 以上，尤其当索引字段本身更新频繁时——这点在慢日志里完全看不到，得靠压测和 SHOW PROFILE 配合看。
