MySQL中OR条件几乎必然导致索引失效，只要任一分支无法走索引，整个WHERE就退化为type: ALL；应优先改写为IN或UNION ALL，或根据业务场景建立复合索引。
MySQL中OR条件几乎必然导致索引失效——不是“可能不走”，而是只要任一分支无法走索引，整个WHERE就退化为type: ALL；即使两边都有单列索引，index_merge也极不稳定，不能当作可靠方案依赖。
EXPLAIN里key为NULL、type为ALL就是索引被弃用的明确信号
这不是bug，是优化器基于成本模型的主动放弃：它预估index_merge要多次回表+排序+去重，开销高于一次顺序全表扫描。比如WHERE name = 'a' OR age = 25，哪怕name和age各自有索引，只要其中任意一个字段选择度低（如gender只有'M'/'F'），或表数据量稍大，优化器就会直接跳过索引。
-
EXPLAIN中key: NULL+type: ALL，基本等于宣告该查询没走任何索引 - MySQL 8.0+虽更倾向启用
index_merge，但依然受数据分布、复合索引是否存在、版本补丁影响，线上不可控 - 混用等值与范围（如
status = 'paid' OR created_at > '2025-01-01'）会让index_merge逻辑更难生效
同字段多值OR必须改写为IN，别碰OR
这是最无脑也最安全的修复方式：status = 'pending' OR status = 'processing'这种写法，无论有没有索引，都应立刻替换成status IN ('pending', 'processing')。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
IN会被优化器识别为等价的离散值匹配，天然支持单列索引的range访问类型 - 避免隐式转换风险：若
status是VARCHAR，IN ('pending', 'processing')比多个OR更易保持类型一致性 - 不要写
IN超过几百项——MySQL对IN列表长度有性能拐点，超限时考虑临时表或分批查
跨字段OR优先用UNION ALL拆分，但必须满足三个硬约束
把“一个查询覆盖两棵树”改成“两个查询各走一棵树”，是目前最可控、上线风险最低的修复路径。
- 每个子查询只能保留一个可索引条件，其余过滤字段必须作为补充谓词加在
WHERE里，例如：SELECT id, name FROM t WHERE status = 'paid'UNION ALLSELECT id, name FROM t WHERE created_at > '2025-01-01' AND status != 'paid' - 显式写出列名，且顺序、类型、NULL性必须完全一致，否则报错
ERROR 1222；严禁用SELECT * - 原查询带
LIMIT或ORDER BY？必须分别在每个子查询里加，否则分页漏数据、排序错乱；外层再套一层ORDER BY+LIMIT会触发Using temporary
什么时候不该拆OR，而该建复合索引
如果OR条件本质是同一业务维度的组合筛选（比如状态+时间），建复合索引比UNION ALL更干净、更少出错。
- 适用场景：
WHERE (status = 'paid' AND created_at > '2025-01-01') OR (status = 'refunded' AND created_at > '2025-01-01')→ 直接建(status, created_at)索引，type: range就能覆盖 - 慎用
UNION ALL的场景：字段值高度重叠（如name和email都可能含'admin'），会导致Using temporary; Using filesort，反而比原OR还慢 - 别为了OR硬凑复合索引——如果
WHERE a = 1 OR b = 2中a和b毫无业务关联，建(a,b)索引只是浪费空间，且可能干扰其他查询
真正麻烦的从来不是“怎么写”，而是“怎么判断该走哪条路”：看EXPLAIN输出是否稳定出现type: ALL，看业务上字段间是否存在天然互斥或强约束，看线上慢查询日志里这条SQL的真实执行耗时与Handler_read_rnd指标——这些细节比记住规则更重要。
