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，第一反应不应该是“怎么让这个索引生效”，而是“能不能换种方式表达需求”。
