or常致全表扫描因优化器遇任一不可索引分支即弃整体索引；应优先用in替代同字段多值or，或用union all拆分跨字段or并确保各子查询独立走索引。
OR 查询不一定慢，但多数情况下它会让优化器放弃索引合并，直接走全表扫描——这时候 UNION ALL 才是可控、可验证的提速手段。
为什么 OR 经常导致 type=ALL
MySQL 优化器对 OR 的处理非常保守：只要任意一个分支无法走索引（比如用了 LIKE '%x'、隐式类型转换、字段无索引），整个查询就大概率退化为 type=ALL。这不是“没选对索引”，而是优化器明确判断“用索引比扫表还慢”。尤其在 MySQL 5.7 及更早版本中，index_merge 默认开启但触发条件极苛刻——所有 OR 字段必须有独立单列索引、不能含函数、不能有前导通配符。
- 执行
EXPLAIN SELECT * FROM t WHERE a = 1 OR b = 2，若其中b没索引，type就是ALL - 哪怕
a和b都有索引，如果WHERE a = 1 OR c LIKE '%test'，c上的索引因前导通配失效，整个OR仍大概率被放弃 - MySQL 8.0 虽加强了
index_merge union，但仅当所有分支都满足等值查询 + 独立单列索引时才稳定生效
UNION ALL 替换 OR 的实操要点
把 WHERE a = 1 OR b = 2 OR c = 3 拆成三个独立查询加 UNION ALL，本质是把“让优化器猜”变成“你指定每条路径怎么走”。但它不是无脑替换，必须满足几个硬前提：
- 每个子查询必须能独立命中索引——先单独跑
EXPLAIN SELECT * FROM t WHERE a = 1，确认type是ref或range，不是ALL或index - 业务逻辑上结果天然不重复（如不同状态、不同时间范围、不同来源字段），才用
UNION ALL；若可能重复，改用UNION会触发临时表 + 排序去重，开销反而更大 - 原查询带
LIMIT或ORDER BY时，不能只在子查询里加——(SELECT ... LIMIT 10) UNION ALL (SELECT ... LIMIT 10)不等于原语义，必须在外层再套一层SELECT ... ORDER BY ... LIMIT - MySQL 5.6 对嵌套
UNION ALL支持差，5.7+ 更稳；若用 5.6，优先考虑建复合索引或改用IN
什么时候该放弃 UNION ALL，转而检查索引设计
如果拆成 UNION ALL 后每个子查询仍是 type=ALL，说明问题不在 OR 本身，而在索引缺失或设计不合理。这时强行拆分只是把一次全表扫描变成三次，性能更差。
- 检查每个
OR字段是否真有单列索引——SHOW INDEX FROM t看清楚是KEY还是复合索引里的非前导列 - 避免在
OR条件中混用函数：UPPER(name) = 'ABC'或DATE(created_at) = '2025-01-01'会让对应字段索引完全失效 - 对高频
OR组合（如status = 0 OR status = 1），直接改用IN更简洁，且 MySQL 对IN的索引利用通常比OR更积极 - 如果字段基数低（如只有 3 种状态），且查询占比高，考虑用覆盖索引减少回表，例如
KEY idx_status_name (status, name)
IN 和 UNION ALL 的取舍边界
IN 在语义清晰、值为等值列表时，通常是比 OR 和 UNION ALL 更轻量的选择；但它不是万能的，尤其当值来自子查询或数量极大时，性能会断崖下跌。
- 值确定且数量少（WHERE status IN (0, 1)，写法干净，优化器识别成熟
- 值来自另一个表关联：避免
WHERE id IN (SELECT id FROM t2 WHERE ...)，MySQL 5.7+ 会转成半连接，但不如显式JOIN可控 - 值数量极大（如几千个 ID）：
IN列表解析和执行计划生成开销上升，此时分批UNION ALL或临时表更稳 - 混合条件（如
WHERE a = 1 OR b > 100 OR c LIKE 'x%'）：IN无法覆盖，只能拆或接受全表扫描
真正卡住性能的往往不是 OR 语法本身，而是背后索引是否匹配、条件是否干净、优化器是否有足够信息做决策——UNION ALL 是把控制权拿回来的工具，不是终点。
