必须用EXPLAIN确认索引是否实际生效，重点看type、key、rows；结合慢日志、performance_schema、sysbench压测及InnoDB缓冲池指标综合验证优化效果。
用 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_nextvsHandler_read_rnd_next：前者是索引有序扫描，后者是随机回表读行。如果后者大幅减少，说明减少了不必要的回表操作
这些指标在 SHOW GLOBAL STATUS 里查，建议在压测前后各采样一次，计算差值比。别只盯 QPS 上升——有时候 QPS 没变，但 buffer pool hit rate 从 92% 升到 99%，这才是索引真正起效的信号。
