本质是优化器因任一分支无法走索引而放弃整体索引，导致全表扫描；应优先用IN替代同字段多值OR，或用UNION ALL拆分跨字段OR并确保各子查询独立走索引。
大量 OR 导致全表扫描，本质是优化器放弃索引
MySQL 遇到多个 OR 条件时，只要其中任意一个分支无法走索引（比如字段没索引、有函数包裹、类型隐式转换），整个 WHERE 就大概率退化为 type=ALL。这不是你写错了 SQL，而是执行计划本身决定不走索引——即使其他分支明明有索引也无济于事。
常见错误现象包括：EXPLAIN 中 key 为空、rows 接近表总行数、查询耗时从毫秒级跳到秒级甚至超时。
- 同一字段的多值判断（如
id = 1 OR id = 2 OR id = 3）→ 优先改用IN - 不同字段的条件组合（如
status = 'A' OR customer_id = 123）→ 必须拆成UNION ALL - 混合了索引列和非索引列（如
name = 'x' OR remark LIKE '%y%'）→ 后者必然拖垮整体，考虑应用层过滤或加全文索引
用 IN 替代同字段 OR：简洁且稳定走索引
IN 是 MySQL 对单字段多等值判断的原生优化方案，只要字段上有索引，就能高效命中 range 类型访问。它比手写一堆 OR 更易读、更少出错，且不会因顺序或括号嵌套引发歧义。
但要注意边界：
-
IN值数量不宜超过 500 个，否则某些 MySQL 版本（尤其是 5.7）会触发临时表或文件排序，反而变慢 -
IN (SELECT ...)不推荐，子查询可能被重写为DEPENDENT SUBQUERY，性能通常不如JOIN -
col IN (1, NULL)不会匹配NULL行，而col = 1 OR col IS NULL可以——行为不一致，别盲目替换
用 UNION ALL 替代跨字段 OR：唯一可控的高性能方案
当 OR 涉及不同字段（如 status = 'shipped' OR customer_id = 123），且各自字段都有独立索引时，UNION ALL 是目前最可靠、最容易验证效果的改写方式。
实操要点：
- 每个子查询必须能独立走索引，先用
EXPLAIN分别验证SELECT * FROM t WHERE status = 'shipped'和SELECT * FROM t WHERE customer_id = 123 - 务必用
UNION ALL，不是UNION；去重开销在大数据量下非常明显，除非业务明确要求去重 - 如果原始查询带
ORDER BY ... LIMIT，不能直接套在外层——要先在每个子查询里加LIMIT（如需取 top N），再合并后二次排序，否则可能漏数据 - 字段顺序、类型、NULL 属性必须完全一致，否则 MySQL 会报错
ERROR 1222 (21000): The used SELECT statements have a different number of columns
容易被忽略的复合索引与执行计划验证
很多人改完 UNION ALL 或 IN 后仍慢，问题常出在索引本身——比如只给 status 加了单列索引，但查询还带 ORDER BY created_at DESC LIMIT 10，这时需要覆盖索引 (status, created_at) 才能避免回表。
关键动作只有两个：
- 对每个子查询单独跑
EXPLAIN，确认type是ref或range，key显示实际索引名，rows显著下降 - 注意 MySQL 8.0 的
index merge确实能处理部分OR，但它不稳定、不可控，且无法配合ORDER BY + LIMIT有效剪枝，别依赖
真正起作用的从来不是“用了 UNION”，而是“每个分支都拿到了自己该拿的索引”。
