type=all表示mysql放弃索引直接全表扫描，常见于多or查询、函数/隐式转换、索引失效等场景；应优先验证各or分支是否独立走索引，再考虑union all拆分或in优化。
EXPLAIN 里看到 type=ALL 就该警觉
当 EXPLAIN 显示 type 是 ALL，说明 MySQL 放弃了所有索引，直接全表扫描——这不是“没走索引”，而是优化器明确判断“用索引比扫表还慢”。尤其在多 OR 场景下，比如 WHERE a = 1 OR b = 2 OR c = 3 OR d LIKE 'x%'，哪怕 a、b、c 都有单列索引，d 上的索引又因 LIKE 前导通配被忽略，优化器大概率会放弃索引合并（index_merge），直接退化为全表扫描。
此时不要急着加索引，先确认：每个 OR 分支单独执行时是否能走索引。例如分别跑：
EXPLAIN SELECT * FROM t WHERE a = 1;<br>EXPLAIN SELECT * FROM t WHERE b = 2;<br>EXPLAIN SELECT * FROM t WHERE d LIKE 'x%';
如果其中任意一个返回 type 是 ALL 或 index（非覆盖扫描），那整个 OR 查询就很难被高效优化。
UNION ALL 拆分不是万能的，但它是可控的第一步
把 WHERE a = 1 OR b = 2 OR c = 3 改成三个独立查询加 UNION ALL，本质是把“让优化器猜怎么合并索引”变成“你明确告诉它每条路径怎么走”。但要注意几个硬约束：
- 每个子查询必须能独立命中索引，否则只是把全表扫描拆成三次
-
UNION ALL不去重，如果业务上天然无重复（如不同字段条件查的是互斥逻辑），这是首选；若可能重复，UNION会触发临时表 + 排序去重，开销可能反超原OR - MySQL 5.7+ 对
UNION ALL的执行计划支持较好，但 5.6 及更早版本在某些嵌套或带ORDER BY/LIMIT场景下仍可能生成低效计划 - 如果原查询有
ORDER BY或LIMIT，不能简单套在外层——(SELECT ... ORDER BY x LIMIT 10) UNION ALL (SELECT ... ORDER BY x LIMIT 10)的结果不等价于原查询，需在外层再ORDER BY ... LIMIT
示例写法：
SELECT id, name FROM users WHERE status = 'active'<br>UNION ALL<br>SELECT id, name FROM users WHERE created_at > '2025-01-01'<br>UNION ALL<br>SELECT id, name FROM users WHERE city = 'Shanghai';
Index Merge 真实可用的前提很苛刻
MySQL 的 index_merge（含 union、sort_union、intersect）不是默认开启的“智能模式”，它只在极少数干净条件下生效：
- 所有
OR字段必须有独立的单列索引（不能是复合索引的一部分，除非该字段是前导列且条件为等值） - 不能混用函数、类型转换、
IS NULL、LIKE前导通配等导致索引失效的操作 - 优化器估算各分支返回行数之和远小于全表行数，否则宁愿扫表
-
EXPLAIN中Extra必须出现Using union(...)，且key列显示多个索引名（如key: idx_a,idx_b）
一旦发现 Extra 是 Using temporary; Using filesort，说明即使启用了 index_merge，后续合并也触发了临时表——这时性能往往不如手动 UNION ALL。
IN 替代多个等值 OR 仅限同一字段
WHERE id = 1 OR id = 2 OR id = 3 OR id = 4 这类同一字段的离散值匹配，必须改用 IN：WHERE id IN (1,2,3,4)。这不是风格问题，而是语义和执行路径差异：
-
IN走的是单次索引查找 + 多个等值匹配，B+ 树只需定位一次范围（如果是主键或唯一索引，就是多次单点查找） - 同等条件下，
IN的执行计划type通常是range或const，而多个OR很可能降级为index_merge甚至ALL - 注意
IN子句元素数量不宜过多（如超 500 个），否则解析和优化开销上升；若来自应用层动态拼接，建议分批查询
但切记：IN 只适用于同一字段。像 WHERE a = 1 OR b = 2 不能写成 WHERE (a,b) IN ((1,?),(?,2))——语法错误，语义也不对。
真正难优化的永远是跨字段、混合操作符、带函数或模糊匹配的 OR。这时候与其反复调索引，不如从查询源头判断：这个条件是否真的必须在同一 SQL 中满足？能否前置到应用层分流？或者用冗余字段（如增加 search_flag）把 OR 逻辑沉淀到写入侧？索引和 UNION 只是手段，不是目的。
