MySQL对OR条件极其保守，只要有一个分支无索引，整个WHERE就退化为全表扫描（type: ALL，key: NULL）；UNION ALL是稳定替代方案，需确保各子句独立命中单列索引。
不是“必须每个条件都有索引才生效”，而是只要有一个OR分支没索引，整个WHERE就大概率退化为全表扫描（type: ALL）——优化器不冒险合并，直接放弃所有索引。
为什么EXPLAIN里key是NULL、type是ALL
MySQL优化器对OR极其保守：它不尝试“一边走索引 + 一边全表扫 + 合并结果”，因为这种混合路径的成本预估模型认为，不如一次顺序全表扫描来得稳定便宜。哪怕id = 1能走主键索引，只要旁边跟着个name = 'alice'（而name没索引），key就会是NULL，type就是ALL。
这不是bug，是InnoDB在5.7+版本中默认行为——index_merge对OR的支持被刻意限制，即使你开了optimizer_switch='index_merge=on'，也只在极窄条件下触发（比如两个单列索引、等值查询、小数据量、无类型转换）。
IN能替代单字段多值OR，但不能解决跨字段OR
-
status = 'paid' OR status = 'refunded'→ 直接改写为status IN ('paid', 'refunded')，MySQL会自动优化，通常走索引 -
status = 'paid' OR created_at > '2025-01-01'→IN完全无用，字段不同，语法不合法 - 误用
IN还可能引入隐式转换：比如phone IN (13800138000)（phone是VARCHAR）→ 索引失效
UNION ALL是目前最可控的修复方式
把“一个查询覆盖两棵树”拆成“两个查询各走一棵树”，强制每个子句独立命中索引：
SELECT id, name FROM users WHERE status = 'paid' UNION ALL SELECT id, name FROM users WHERE created_at > '2025-01-01' AND status != 'paid';
注意几个硬性前提：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 每个子查询的
WHERE条件必须落在**已存在的单列索引**上（status有索引、created_at也有索引） - 第二条里的
AND status != 'paid'是为了去重；若业务上天然互斥（比如状态和时间有强约束），可删——删了更快，且避免Using temporary - 必须显式写出相同列名、相同顺序、相同类型，否则报错
ERROR 1222 - 原查询带
LIMIT或ORDER BY？得分别加在子查询里，外层再套一层，否则分页错乱
复合索引对OR几乎没用，除非写法特殊
建了(status, created_at)联合索引，并不能让status = 'paid' OR created_at > '2025-01-01'走索引——因为created_at > ...不满足最左前缀，B+树无法连续扫描。
真正能用上联合索引的OR，仅限于这种结构：
WHERE (status = 'paid' AND created_at > '2025-01-01') OR (status = 'refunded' AND created_at > '2025-01-01')
这时type: range才可能生效。但这种情况本质是“同一维度的组合条件”，已经不是典型OR问题了。
实际调试时，别依赖EXPLAIN里偶尔出现的index_merge，它不稳定、不可控、难复现——UNION ALL才是生产环境敢写的方案。
