mrr（multi-range read）在查询走二级索引、需回表且主键值分布离散时生效，典型场景如where status in (1,2,3)或order by created_at limit 100；不适用于主键查询或覆盖索引。
什么是 MRR，它在什么情况下真正起作用
MRR（Multi-Range Read）不是自动开启的银弹，它只在满足特定条件时才被优化器选中：查询走二级索引 + 回表 + 且回表的主键值分布离散。典型场景是 WHERE status IN (1,2,3) 或 ORDER BY created_at LIMIT 100 这类先用二级索引筛选、再查聚簇索引的语句。如果直接查主键、或二级索引覆盖了所有需要字段（无需回表），MRR 就不会触发。
如何确认当前查询是否用了 MRR
不能靠猜，得看执行计划里的 Extra 字段：
- 出现
Using MRR—— 确实启用了 - 出现
Using index condition; Using MRR—— 同时用了 ICP 和 MRR，常见于带范围条件的LIKE或函数索引场景 - 只有
Using index condition没有 MRR —— 可能因为read_rnd_buffer_size太小，或结果集太小（默认阈值约 10 行以下不启用）
执行 EXPLAIN FORMAT=JSON 还能看到 mrr 和 mrr_cost 字段，比传统 EXPLAIN 更准。
怎么调参让 MRR 更大概率生效
MRR 的开关和效果受两个关键参数控制，不是开就一定快：
-
mrr必须为ON（默认是ON，但某些旧版本或配置可能关掉） -
read_rnd_buffer_size决定排序缓冲区大小，直接影响 MRR 是否启用及效率；太小（如默认 256K）会导致小结果集跳过 MRR，建议设为1M～4M，但注意这是每个连接独占内存，别全局设太高 - 若强制想禁用 MRR 调试对比，可用
SELECT /*+ NO_MRR(t) */ ...（MySQL 8.0.20+）
改完记得用 SHOW VARIABLES LIKE 'read_rnd_buffer_size' 确认生效，动态变量需对当前 session 生效，全局修改要加 GLOBAL。
MRR 带来的实际性能变化和坑点
好处明显：把随机回表变成按主键排序后的顺序读，IO 减少 30%～70%，尤其在机械盘或高并发回表场景下提升显著。但要注意几个反直觉点：
- 启用 MRR 后，
EXPLAIN显示的rows可能变大——因为优化器预估的是“排序前”的行数，不是最终输出行数，别误判为变慢 - 如果二级索引本身就很宽（比如联合索引包含多个大字段），MRR 排序开销反而可能超过收益
- 在
GROUP BY或DISTINCT场景下，MRR 可能被绕过，因为优化器优先保证逻辑正确性而非 IO 优化
真正要验证效果，得跑真实负载 + sys.schema_table_statistics 对比 rnd_next 和 rnd_pos 次数变化，而不是只看执行时间——有时候时间没差，但磁盘压力已经降了一半。
