mysql索引优化后如何验证效果_mysql性能测试方法

必须用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_next vs Handler_read_rnd_next：前者是索引有序扫描，后者是随机回表读行。如果后者大幅减少，说明减少了不必要的回表操作

这些指标在 SHOW GLOBAL STATUS 里查，建议在压测前后各采样一次，计算差值比。别只盯 QPS 上升——有时候 QPS 没变，但 buffer pool hit rate 从 92% 升到 99%，这才是索引真正起效的信号。