mysql索引优化后如何验证效果_mysql性能测试方法_网络技术

发布时间 - 2026-02-01 00:00:00 点击率：次

必须用EXPLAIN确认索引是否实际生效，重点看type、key、rows；结合慢日志、performance_schema、sysbench压测及InnoDB缓冲池指标综合验证优化效果。

加了索引不等于用了索引，必须确认查询实际走的是你建的那条。在 SELECT 语句前加 EXPLAIN，重点看 type（越靠前越好，ref/range 比 ALL 强）、key（是否显示你新建的索引名）、rows（预估扫描行数是否显著下降）。

常见误判点：

开发环境 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 跑相同数据量、相同并发、相同读写比例的 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 条件改成目标字段，否则压测根本打不到新索引上。

索引优化最终要落到 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%，这才是索引真正起效的信号。