bka不会自动生效，必须同时满足mrr=on、mrr_cost_based=off、被驱动表有可用二级索引且驱动表输出行数足够多，否则优化器将退化为inlj，explain中不会显示using join buffer (batched key access)。
BKA 不是开个开关就能生效的“银弹”，它必须和 MRR 协同工作，且只在特定索引条件下起效。 如果你启用了 batched_key_access=on 却没看到执行计划里出现 Using join buffer (Batched Key Access)，大概率是漏掉了关键前提或配置冲突。
为什么 EXPLAIN 看不到 BKA？常见失效原因
MySQL 优化器不会主动选择 BKA，除非所有条件同时满足：
-
mrr必须为on（默认是 on，但可能被显式关掉） -
mrr_cost_based必须为off—— 这是最常踩的坑：默认值虽是 off，但若你之前设过on或通过配置文件覆盖，BKA 就会静默退化回 INLJ - 被驱动表上必须有可用索引（等值条件列需命中索引最左前缀），且该索引不能是主键（BKA 对主键索引效果有限，真正受益的是二级索引回表场景）
- 驱动表输出行数不能太少（比如
-
join_buffer_size太小（
如何确认 BKA 是否真正启用？
不能只看 optimizer_switch 设置，必须查执行计划：
运行 EXPLAIN FORMAT=TREE 或 EXPLAIN 后观察 Extra 列：
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
- 出现
Using join buffer (Batched Key Access)→ 成功启用 - 出现
Using where; Using index condition但无 BKA 提示 → 可能走了 MRR，但没触发 BKA（比如驱动表太小或索引不匹配） - 只有
Using index condition→ 回退到普通 INLJ，随机 I/O 仍在
注意：FORMAT=TREE 在 MySQL 8.0+ 才支持，5.7 只能靠 Extra 文本判断。
batched_key_access 和 mrr 的参数设置顺序有影响吗？
没有顺序依赖，但必须同时开启且正确配置：
- 推荐一次性设置：
SET SESSION optimizer_switch='mrr=on,mrr_cost_based=off,batched_key_access=on'; -
GLOBAL级设置会影响所有新连接，但已有连接不受影响；SESSION级更安全，适合调试单条 SQL - 不要写错参数名：
mmr（少一个 r）或mrr_cost_base（少一个 d）会导致设置失败且无报错 - 验证是否生效：
SELECT @@optimizer_switch;查看返回字符串中对应项是否为on
BKA 在什么 JOIN 场景下收益最大？
它不是通用加速器，而是专治“二级索引 + 大量回表”的典型瓶颈：
- 驱动表较大（比如 10k+ 行），被驱动表有二级索引但无覆盖索引（需要回主键查完整行）
- JOIN 条件是等值匹配（
=），且该列上有非唯一二级索引（如status、category_id） - 磁盘 I/O 是瓶颈（尤其机械盘或高延迟云盘），此时批量排序 + 顺序读提升显著
- 反例：驱动表仅几百行、被驱动表用主键 JOIN、或条件走范围查询（
>、BETWEEN）——BKA 效果弱甚至无效
真正容易被忽略的是：BKA 的收益高度依赖数据物理分布。如果二级索引对应的主键值本身已近似有序（比如按时间插入），MRR 排序带来的增益会打折扣；反之，若二级索引键值散乱而主键高度有序，BKA 的 I/O 优化就非常明显。
