根本原因是InnoDB 5.7+缺乏安全可控的索引合并机制，OR分支需全部命中独立单列索引且无类型转换或范围混用，否则优化器直接退化为全表扫描。
MySQL 执行含 OR 的 SQL 时容易退化为全表扫描，根本原因不是优化器“不想用索引”，而是它在 InnoDB 5.7+ 下**缺乏安全、可控的索引合并机制**，多数情况下只能二选一：要么硬凑 index_merge（失败率高），要么直接放弃索引走 type=ALL。
为什么 OR 在 InnoDB 5.7 中基本不触发 index_merge
InnoDB 默认关闭 index_merge，即使手动开启 optimizer_switch='index_merge=on'，生效条件也极其苛刻：
- 每个
OR分支必须对应一个**独立的单列索引**（不能是复合索引的前缀，也不能是函数索引） - 所有分支都不能含隐式类型转换（如
phone = 138而 phone 是VARCHAR） - 不能混用范围条件和等值条件（如
id = 1 OR age > 30就大概率被拒） - 若任一分支字段无索引（如
name = 'a' OR city = 'b'中city未建索引），整个查询直接退化为全表扫描
EXPLAIN 看到 type=ALL 就该立刻验证各分支是否独立可用索引
type=ALL 是明确信号：优化器已放弃所有索引路径。此时别急着加索引或调参数，先拆开验证：
- 单独执行
EXPLAIN SELECT * FROM t WHERE a = 1; - 再执行
EXPLAIN SELECT * FROM t WHERE b = 2; - 最后执行
EXPLAIN SELECT * FROM t WHERE c LIKE 'x%';
只要其中任意一个返回 type=ALL 或 type=index（非覆盖扫描），整个 OR 查询就不可能高效——因为优化器无法把“不可用”的分支合并进有效路径。
UNION ALL 拆分不是取巧，而是把控制权拿回来
用 UNION ALL 替代 OR，本质是绕过优化器对多路径合并的不可靠判断，转为显式声明每条路径的索引使用方式：
- 每个子查询必须能独立命中索引（否则只是把一次全表扫描变成 N 次）
- 字段顺序和类型必须严格一致，否则报错：
SELECT id, name FROM t WHERE name = 'a' UNION ALL SELECT id, name FROM t WHERE city = 'b'; - 原查询若有
ORDER BY或LIMIT，必须加在外层：(SELECT ...) UNION ALL (SELECT ...) ORDER BY id LIMIT 10，不能只在子查询里加 - 确认业务上无重复数据时，坚持用
UNION ALL；若需去重，UNION会触发临时表 + 排序，开销可能反超原OR
IN 并不比 OR 更可靠，尤其在 5.7 中
IN 在语法上更简洁，但 MySQL 5.7 中它只是 OR 的等价展开，底层仍受同样限制：
-
WHERE status IN ('A','B','C')若status基数低（比如只有 3 个值）、表又很大，优化器可能认为回表成本太高，直接选全表扫描 -
WHERE phone IN (13800138000, 13900139000)中数字字面量触发隐式转换，索引立即失效 -
WHERE created_at IN ('2024-01-01', '2024-01-02')表面看没问题，但一旦写成DATE(created_at) IN (...)，索引就彻底作废
真正起效的前提，从来不是换写法，而是确保每个条件列都有匹配的、干净的单列索引，并且查询中没有任何隐式转换或函数包裹——这点最容易被忽略，也最常导致“明明建了索引却没用”。
