用 EXPLAIN
看执行计划是否真的走了新索引
加了索引不等于用了索引，必须确认查询实际走的是你建的那条。在
SELECT语句前加
EXPLAIN，重点看
type（越靠前越好，
ref/
range比
ALL强）、
key（是否显示你新建的索引名）、
rows（预估扫描行数是否显著下降）。
常见误判点：
key为空或显示其他索引名 → 索引未命中，可能是
WHERE条件没覆盖索引最左前缀，或存在隐式类型转换（比如字符串字段用数字比较）
rows和表总行数接近 → 实际还是全表扫描，索引可能失效或选择性太低 用了
ORDER BY但
Extra出现
Using filesort→ 排序无法利用索引，需检查是否能把排序字段加入联合索引末尾
用 SLOW_LOG
和 performance_schema
抓真实慢查询
开发环境
EXPLAIN看得再好，也代替不了线上真实流量下的表现。开启 MySQL 慢查询日志，设置
long_query_time = 1（甚至 0.5），让业务跑一段时间后分析日志： 用
mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log找出耗时 top 10 的语句 对比优化前后同一 SQL 的平均执行时间、锁等待次数、扫描行数（
Rows_examined） 启用
performance_schema后，查
events_statements_summary_by_digest表，能按指纹聚合统计，避免被参数化差异干扰
注意：不要只看单次执行时间，要关注 P95/P99 延迟和抖动——有些 SQL 平均快了，但偶发卡顿更严重，可能是因为索引导致回表放大或锁竞争加剧。
用 sysbench
做可控压测对比
想量化索引优化收益，就得控制变量压测。用
sysbench跑相同数据量、相同并发、相同读写比例的 OLTP 场景： 先用
sysbench oltp_read_write --tables=16 --table-size=1000000 prepare初始化数据 分别对原表和加索引后的表执行
run，记录
queries per second和
latency (avg/max)关键要看
95th percentile latency是否下降，以及
MySQL Threads_running峰值是否降低 —— 后者反映锁/IO压力是否缓解
容易忽略的一点：
sysbench默认用主键范围扫描，如果你优化的是非主键字段，得自定义 Lua 脚本把 WHERE 条件改成目标字段，否则压测根本打不到新索引上。
监控 InnoDB_buffer_pool_reads
和 Handler_read_*
指标
索引优化最终要落到 IO 和内存效率上。观察以下两个关键指标的变化：
InnoDB_buffer_pool_reads：每秒从磁盘读取页的次数。优化后该值应明显下降，说明更多数据从 buffer pool 命中
Handler_read_nextvs
Handler_read_rnd_next：前者是索引有序扫描，后者是随机回表读行。如果后者大幅减少，说明减少了不必要的回表操作
这些指标在
SHOW GLOBAL STATUS里查，建议在压测前后各采样一次，计算差值比。别只盯
QPS上升——有时候 QPS 没变，但
buffer pool hit rate从 92% 升到 99%，这才是索引真正起效的信号。
