or条件混在子查询中会导致索引失效，应拆分为in或union all并确保各分支有对应单列索引，标量子查询含or需改left join或cte物化，not in+or组合须优先替换为not exists或left join，index_merge对or支持有限且依赖严格条件。
OR条件混在子查询里，先拆再索引
嵌套子查询里带大量OR，基本等于主动放弃索引。比如WHERE id IN (SELECT id FROM t WHERE a = 1 OR b = 2 OR c > 100)，MySQL 很可能对整个子查询走全表扫描，外层再拿结果去关联，CPU 和 IO 双爆。这不是写法“不够优雅”的问题，是执行路径被锁死了。
实操建议：
- 把子查询里的
OR先单独拎出来：确认是不是同一字段多值（如status = 'A' OR status = 'B'），能改IN就立刻改，别犹豫 - 跨字段的
OR（如a = 1 OR b = 2）必须拆成UNION ALL子查询，且每个分支都要有对应字段的单列索引 - 拆完后用
EXPLAIN逐个验证：每个SELECT分支的type必须是ref或range，key列不能为NULL - 如果子查询本身还带
GROUP BY或LIMIT，别指望优化器自动下推——得手动在每个UNION ALL分支里加，再外层统一ORDER BY和LIMIT
标量子查询里套OR，CPU飙升的元凶
像SELECT name, (SELECT COUNT(*) FROM log WHERE user_id = u.id AND (action = 'login' OR action = 'logout')) FROM users u这种写法，看着逻辑清楚，实际每行u.id都会触发一次含OR的子查询，数据库没法复用执行计划，CPU 就耗在反复解析和扫描上。
实操建议：
- 直接重写为
LEFT JOIN+GROUP BY：先聚合日志，再关联用户，避免逐行执行 - 若必须保留子查询结构，把
OR部分提前物化：用WITHCTE 先算出所有匹配action的user_id集合，再在子查询里IN这个结果集 - 检查
log(action)是否有索引；没有就建，但注意OR本身不会让这个索引失效，失效的是你在WHERE里对action用了函数（比如UPPER(action)） - MySQL 8.0+ 可尝试开启
optimizer_switch='semijoin=on'，部分场景能自动把IN (subquery)转为半连接，但前提是子查询不带OR或GROUP BY
NOT IN + OR 组合，优先砍掉NOT IN
WHERE id NOT IN (SELECT id FROM t WHERE a = 1 OR b = 2)这种写法，危险系数拉满。子查询返回任意一个NULL，整个NOT IN就返回空结果；更糟的是，优化器大概率放弃使用索引，直接走临时表 + 全量比对。
实操建议：
- 第一步永远是干掉
NOT IN：改用NOT EXISTS或LEFT JOIN ... IS NULL，前者语义清晰，后者在 MySQL 中通常更稳 - 第二步再处理
OR：把子查询里的OR按前面说的拆成UNION ALL，确保两个分支都能走索引 - 如果子查询结果集大（>1000 行），
NOT EXISTS可能比LEFT JOIN慢，因为要对每行外层数据做“是否存在”判断；这时宁可多建一个覆盖索引，也要避免NOT IN - 别信“加了索引就没事”——
NOT IN在子查询字段存在NULL时，索引压根不会被用于反向过滤
为什么你加了索引，OR还是不走？
很多人建了INDEX(a)和INDEX(b)，以为a = 1 OR b = 2就能触发index_merge，结果EXPLAIN里还是type: ALL。这不是 bug，是 MySQL 的index_merge有硬性门槛：它要求所有OR分支都是等值查询、不能有函数、不能隐式转换、且优化器评估成本低于全表扫描。
实操建议：
- 用
EXPLAIN FORMAT=JSON看used_key_parts和index_merge是否真被启用；没出现就说明没走 - 把
OR换成UNION ALL后，每个分支的EXPLAIN必须单独跑，不能只看外层 - 如果
OR里混了范围条件（如c > 100）或IS NULL，index_merge基本无望，强行依赖只会拖慢调试节奏 - 真正卡住的点往往不在 SQL 写法，而在数据分布——比如
a = 1命中 95% 行，b = 2命中 0.1% 行，优化器会直接放弃合并，选最差的那个走全表
UNION ALL分支，字段顺序、类型、可空性必须完全一致，否则报错ERROR 1222；而一旦加了CAST或COALESCE来对齐，又可能让索引失效——这时候就得权衡，是改数据模型，还是接受某一层的扫描。
