or破坏b+树有序路径，因多字段匹配无法共用单条有序扫描；优化器权衡随机回表i/o与顺序全表扫描成本后常弃用索引，仅当各or分支均独立命中有效索引时才可能触发index merge。
OR破坏B+树的有序遍历路径
MySQL的B+树索引依赖字段值的有序排列来实现高效查找。当WHERE中出现a = 1 OR b = 2时，优化器无法用单条有序路径同时覆盖两个字段的匹配位置——a索引里的主键ID序列和b索引里的主键ID序列彼此无关，中间可能隔着大量无关数据。这种“多起点、非连续”的语义，天然违背B+树一次扫描就能定位结果的设计前提。
优化器成本估算让索引变“更贵”
即使a和b各自有单列索引，MySQL也不会默认启用Index Merge。它会对比两种执行路径的成本：
- 走
a索引 + 回表取行 + 再全表扫一遍找b匹配项（含多次随机I/O） - 直接全表扫描一次（纯顺序I/O）
由于随机I/O成本远高于顺序I/O，只要回表行数稍多，优化器就会判定“走索引反而更慢”，于是选type: ALL。这不是bug，是基于代价模型的理性放弃。
Index Merge不是万能开关
MySQL 8.0虽支持index_merge_union，但触发条件极严：
- 每个OR分支必须对应一个**独立可用**的索引（不能含函数、
IS NULL、隐式转换） - 不能混用索引列和非索引列（如
name = 'x' OR remark LIKE '%y%'） - EXPLAIN里要看到
Extra: Using union(a,b)才算真正生效；若仍显示key: NULL，说明合并被跳过
现实中，只要有一个分支不满足条件，整个OR就退回全表扫描——你加了两个索引，可能只因一个LIKE '%xxx'就全作废。
同一字段的OR其实早被优化了
像status = 'A' OR status = 'B' OR status = 'C'这类写法，MySQL会自动重写为status IN ('A','B','C')并走索引，无需手动改。真正危险的是跨字段、混合类型、带函数或模糊匹配的OR。别盯着“有没有OR”，要看“OR两边能不能各自独立走索引”。
最容易被忽略的一点：UNION ALL拆分后，每个子查询的WHERE条件必须严格对应一个索引字段，且不能额外加导致失效的操作（比如在子查询里再套UPPER(name)）。索引不是加了就生效，是“用对了才生效”。
