MySQL 中使用
OR条件容易导致索引失效，进而引发全表扫描，性能明显下降。核心优化思路是：**避免让 OR 破坏索引的有序性，优先用 UNION 替代 OR，或确保所有 OR 分支都能命中同一索引的不同列（且该索引是复合索引并满足最左前缀）**。
用 UNION ALL 替代 OR（最常用有效）
当 OR 连接的是不同字段的等值条件（如
WHERE a=1 OR b=2），且 a、b 各自有独立索引时，MySQL 通常无法同时利用两个索引。此时可拆成两个独立查询，用
UNION ALL合并结果：
SELECT * FROM t WHERE a = 1;
SELECT * FROM t WHERE b = 2;合并为：
SELECT * FROM t WHERE a = 1 UNION ALL SELECT * FROM t WHERE b = 2;
注意：若需去重，用
UNION；若确认无重复或允许重复，用
UNION ALL更快。每个子查询可各自走索引，效率远高于原 OR 查询。
为 OR 字段建立合适的复合索引
如果 OR 条件都作用于同一张表的几个字段（如
WHERE status = 'A' OR status = 'B'），本质是单字段多值匹配，直接用
IN更清晰高效：
WHERE status IN ('A', 'B')，配合 status单列索引即可。
若必须用 OR 且涉及多个字段（如
WHERE (a = 1 AND b = 2) OR (a = 3 AND b = 4)），可考虑创建联合索引
(a, b)—— 因为每个分支都符合最左前缀，MySQL 可能使用索引范围扫描（取决于版本和统计信息）。
避免在 OR 中混用索引列与非索引列
例如：
WHERE indexed_col = 1 OR non_indexed_col = 'x'。只要有一个分支无法走索引，整个 WHERE 就大概率退化为全表扫描。解决方法： 给
non_indexed_col添加索引（如果查询频繁且选择性好） 改写逻辑，把非索引条件移到应用层过滤（适合结果集较小的场景） 用覆盖索引 + 子查询等方式减少回表，但需权衡复杂度
检查执行计划，确认是否真的走索引
无论怎么改写，都要用
EXPLAIN验证效果： 看
type是否为
ref、
range或
index，避免
ALL看
key列是否显示实际使用的索引 对比
rows预估扫描行数，优化后应显著减少
特别提醒：MySQL 5.7+ 对 OR 的优化有所增强，但仍有局限；8.0 在某些场景下支持“index merge”，但不如 UNION 稳定可控。
