直接拆成UNION ALL通常是最快见效的方案，但前提是每个分支都能独立走索引；否则只是把全表扫描拆成多次全表扫描。
直接拆成 UNION ALL 通常是最快见效的方案，但前提是每个分支都能独立走索引——否则只是把全表扫描拆成多次全表扫描。
OR 条件导致索引失效的典型场景
MySQL 在遇到跨字段的 OR（比如 WHERE status = 'paid' OR customer_id = 123）时，往往放弃使用任一索引，转为全表扫描。根本原因不是语法问题，而是 B+ 树索引不支持高效合并多个不连续范围的查找结果。
常见错误现象包括：
- 执行
EXPLAIN显示type: ALL，即使status和customer_id各自都有单列索引 - 慢查询日志中该语句
rows_examined接近表总行数 - 加了复合索引
(status, customer_id)也没用——因为OR不满足最左前缀匹配规则
UNION ALL 拆分必须满足的三个前提
不是所有 OR 都适合拆。盲目替换反而更慢。
- 每个子查询的
WHERE条件必须能命中**独立可用的索引**（例如status有索引、customer_id也有索引） - 各分支之间**无强业务互斥要求**：如果允许少量重复（如同一行同时满足两个条件），就用
UNION ALL；否则得加DISTINCT或外层去重，开销陡增 - 避免在子查询里带
GROUP BY/HAVING/ORDER BY：这些会迫使每个分支先聚合或排序，再合并，代价远高于原OR
IN 替代同一字段 OR 更简单高效
如果 OR 全部作用于同一个字段（如 WHERE type = 1 OR type = 2 OR type = 5），优先改写为 IN。
-
IN(1,2,5)和等价OR逻辑一致，但优化器对IN的索引利用更稳定 - 不需要额外建索引，也不用拆查询，可读性和维护性都更好
- 注意：MySQL 8.0+ 对
IN子查询做了深度优化，但若子查询返回上万行，仍可能退化为临时表 + 关联，此时不如先物化结果
实际改写时容易踩的坑
看似简单的一行替换，常因细节翻车：
- 漏掉子查询中的共用过滤条件：比如原
WHERE deleted = 0 AND (a = 1 OR b = 2)，拆成UNION ALL时，deleted = 0必须写进**每个子查询的 WHERE 中**，否则语义不等价 - 字段顺序/别名不一致：多个
SELECT的列数、类型、顺序必须完全相同，否则报错ERROR 1222 (21000): The used SELECT statements have a different number of columns - 忽略 NULL 值行为：
WHERE col = 1 OR col IS NULL拆成两个子查询时，IS NULL分支需单独建函数索引（如INDEX(col, id)）才能走索引，否则仍是全表扫描
真正关键的不是“能不能拆”，而是拆完每个分支是否真能走索引——务必用 EXPLAIN FORMAT=TREE 看执行计划，确认每条 SELECT 的 possible_keys 和 key 都非空。否则，你只是把一个慢查询，复制粘贴成了两个慢查询。
