MySQL 中 OR 易致索引失效，应优先用 UNION ALL 替代；确保 OR 各分支均命中同一复合索引的最左前缀；避免混用索引与非索引列；务必用 EXPLAIN 验证执行计划。
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 稳定可控。
