or条件通常导致全表扫描，因b+树索引无法合并不相交路径；mysql 8.0+仅在各分支均有独立单列索引、无函数/类型转换、数据分布均匀时才启用index_merge_union。
OR破坏B+树的有序遍历路径
MySQL的B+树索引本质是单路径有序结构，一次查询只能高效走一条连续键值路径。WHERE a = 1 OR b = 2要求同时匹配两个不相交的数据片段——a=1可能落在索引树左半边，b=2可能散落在右半边。优化器无法把这两段“拼”成一个连续扫描区间，强行走索引就得做多次随机回表，成本反而高于顺序全表扫描。
优化器基于成本放弃索引
即使a和b各自有单列索引，MySQL也不会默认启用index_merge_union。它会估算两种路径成本：
- 走
a索引 + 回表 + 再全表扫一遍找b=2的行（含大量随机I/O） - 直接全表扫描一次（纯顺序I/O）
由于随机I/O权重远高于顺序I/O，只要回表行数稍多，优化器就选后者——EXPLAIN里type: ALL、key: NULL就是这个决策结果。
哪些OR能触发索引合并？
MySQL 8.0+的index_merge_union生效条件极严，必须同时满足：
- 每个OR分支都对应一个**独立可用的单列索引**（不能是联合索引的非最左前缀）
- 分支中不能出现函数、隐式类型转换、
IS NULL、LIKE '%xxx'等干扰项 - 字段数据分布不能太倾斜（比如
b = 'xxx'命中90%的行，合并代价爆炸）
现实中只要有一个分支不达标，整个OR就退化为全表扫描——不是你没建索引，而是优化器主动绕开了它。
UNION ALL拆分后仍全表扫描？检查这三点
改写成SELECT * FROM t WHERE a=1 UNION ALL SELECT * FROM t WHERE b=2后还是慢，大概率卡在这几个地方：
-
a或b字段**没索引**，或索引被隐式转换干掉了（比如WHERE phone = 13800000000但phone是VARCHAR） - 子查询里混用了
ORDER BY或LIMIT（它们不能下推到UNION分支内，会导致临时表） - 业务上需要去重，却误用了
UNION而非UNION ALL，触发额外排序和临时表
真正关键的不是语法改写，而是每个SELECT子句单独跑EXPLAIN，确认type是ref或range，且key显示命中了对应索引。
