为什么MySQL中的OR条件会导致查询无法命中联合索引

OR条件破坏联合索引最左前缀匹配规则，因无法构造连续索引扫描路径；即使有联合索引(a,b)，WHERE a=1 OR b=2也无法有效利用，优化器常选择全表扫描；index_merge union不可靠且低效；UNION ALL重写需额外单列索引支持；唯一稳妥走联合索引的OR是各分支均严格满足最左前缀。

OR条件破坏联合索引最左前缀匹配规则

MySQL 的联合索引（如 (a, b, c)）依赖最左前缀原则：只有查询条件从左到右连续匹配索引列时，才能有效利用索引。而 OR 把多个不相关的等值或范围条件强行并列，导致优化器无法构造出一个连续的索引扫描路径。

比如 WHERE a = 1 OR b = 2，即使有联合索引 (a, b)，优化器也无法同时用上 a 和 b 的位置关系——因为 a = 1 对应索引开头片段，b = 2 却散落在不同 a 值的子树里，物理上不连续。

• 联合索引本质是 B+ 树按 (a,b) 排序的有序结构，b = 2 单独出现时，必须跳过所有 a 分支逐个查找，成本高
• 优化器评估后认为：不如全表扫描一次，比多次随机跳转更便宜
• 即使 OR 两边都命中同一联合索引（如 WHERE (a=1 AND b=2) OR (a=1 AND b=3)），8.0+ 可能走 range，但这是特例，不能依赖

OR触发Index Merge但不可控且低效

当 a 和 b 各有单列索引时，MySQL 5.7+ 可能启用 index_merge，在执行计划中看到 type: index_merge、key: idx_a,idx_b。但这不是稳定策略。

• index_merge 默认在 5.7 关闭，8.0 虽默认开启，但仅对 AND 下的交集（intersection）较可靠；OR 对应的是 union 模式，实际启用率很低
• 是否启用取决于行数估算、索引选择度、缓冲区大小等隐式参数，同一语句在不同数据量下可能走完全不同路径
• 即使启用，index_merge union 仍需合并多个索引结果集，涉及临时表和去重，性能常不如预期

UNION ALL重写时联合索引反而更难复用

有人试图把 WHERE a = 1 OR b = 2 拆成 SELECT ... WHERE a = 1 UNION ALL SELECT ... WHERE b = 2，期望每个分支走各自索引。但如果只建了联合索引 (a, b)，第二个子查询 WHERE b = 2 依然无法使用它。

• b 不是最左前缀，联合索引 (a,b) 对 b = 2 完全无效（除非加 WHERE a IS NOT NULL AND b = 2，但语义已变）
• 此时必须额外建单列索引 idx_b(b)，否则第二分支仍是全表扫描
• 联合索引设计初衷是服务 WHERE a = ? AND b = ? 或 WHERE a = ? ORDER BY b 这类场景，不是为 OR 准备的

真正能走联合索引的OR写法极少

绝大多数 OR 场景都不该指望联合索引生效。唯一较稳妥的情况是：所有 OR 分支都严格满足最左前缀，且字段顺序一致。

• 例如：索引 (status, created_at)，查询 WHERE (status = 'paid' AND created_at > '2024-01-01') OR (status = 'refunded' AND created_at > '2024-01-01') —— 这可能走 range，因 status 是等值，created_at 是共同范围条件
• 但一旦变成 WHERE status = 'paid' OR created_at > '2024-01-01'，联合索引就彻底失效
• 别为了迁就 OR 去堆砌冗余联合索引，优先考虑业务层拆查或改用 IN / 状态归类

联合索引不是万能胶，它的价值在于减少回表和排序，而不是兜底所有逻辑组合。遇到 OR，第一反应不应该是“怎么让这个索引生效”，而是“能不能换种方式表达需求”。