mrr仅对满足“二级索引扫描→必须回表→主键物理离散”三要素的查询生效，如where status in (1,2,3)或between范围查询；覆盖索引、主键扫描、函数索引等场景不触发mrr，需通过explain format=json确认"using_mrr": true及sys.schema_table_statistics中rnd_next下降来验证真实启用。
MRR 不是默认就生效的“加速开关”，它只在特定回表场景下被优化器选中，且效果高度依赖数据分布和参数配置。盲目调大 read_rnd_buffer_size 或强制开启 mrr_cost_based=off 反而可能拖慢查询。
哪些查询能真正触发 MRR？
MRR 只对满足“二级索引扫描 → 必须回表 → 主键物理离散”三要素的查询起作用：
-
WHERE status IN (1,2,3)（二级索引查出多个主键，再回表） -
WHERE created_at BETWEEN '2025-01-01' AND '2025-12-31' ORDER BY id LIMIT 100（范围条件走二级索引，需回表取全行） -
WHERE category = 'A' AND price > 100（联合索引最左匹配后带范围，回表不可避免）
以下情况 MRR 完全不参与：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
SELECT id, name FROM t WHERE status = 1（覆盖索引，无需回表） -
SELECT * FROM t WHERE id > 1000（直接主键扫描，无二级索引参与） -
WHERE JSON_CONTAINS(data, '"abc"')（虚拟列或函数索引不支持 MRR）
怎么确认 MRR 真的在跑？
不能只看 EXPLAIN 的 Extra 列是否含 Using MRR —— 它可能被跳过或隐藏。必须组合验证：
- 执行
EXPLAIN FORMAT=JSON，检查输出中是否存在"using_mrr": true和"mrr_cost"字段（值为正数才表示启用） - 观察
Extra：出现Using index condition; Using MRR表示 ICP 和 MRR 同时生效；只有Using index condition没有MRR，大概率是read_rnd_buffer_size太小或预估行数低于阈值（默认约 10 行） - 查系统表：
SELECT * FROM sys.schema_table_statistics WHERE table_name = 'your_table'，对比rnd_next（随机读次数）是否明显下降、rnd_pos（顺序读次数）是否上升
关键参数怎么调才有效？
mrr 和 read_rnd_buffer_size 是影响 MRR 是否启用的核心变量，但调法有反直觉点：
-
mrr=on是前提（MySQL 5.7 默认开启），但开启 ≠ 生效；mrr_cost_based=on（默认）表示优化器按成本估算决定是否启用，设为off会强制启用，容易在小结果集或宽索引场景下适得其反 -
read_rnd_buffer_size太小（如默认 256K）：小结果集直接跳过 MRR，走传统随机回表；太大（如 16M）：单连接独占内存暴涨，高并发下易 OOM；若二级索引本身很宽（比如含TEXT列），排序开销可能反超 IO 节省 - 推荐实操值：
SET SESSION read_rnd_buffer_size = 4194304（4M），改完必须在同 session 跑EXPLAIN或真实查询才能验证效果
为什么有时候 EXPLAIN 显示 rows 变大了？
启用 MRR 后，EXPLAIN 的 rows 值反映的是“排序前”的主键数量，不是最终输出行数。这是优化器预估的中间态，不代表变慢 —— 实际 IO 压力可能已大幅下降。真正要判断效果，得看 sys.schema_table_statistics 中 rnd_next 是否显著减少，而不是只盯执行时间。主键局部性好（如自增 ID + 小范围条件）时，MRR 收益极低，甚至不如原方式，这点最容易被忽略。
