UNION ALL 拆分对聚合查询基本无效，强行拆会出错或结果错误；必须先确认是否真需聚合，再决定能否拆分，且非互斥条件必须用 UNION 去重或条件聚合。
直接结论：UNION ALL 拆分对聚合查询（如 COUNT/SUM/GROUP BY）基本无效，强行拆会出错或结果错误——必须先明确是否真需要聚合，再决定是否能拆。
UNION ALL 不能直接套用在带 GROUP BY 或聚合函数的 OR 查询上
MySQL 不允许在 UNION 的子查询中直接使用 GROUP BY（除非用派生表包裹），更不允许 SELECT COUNT(*) FROM t WHERE a=1 OR b=2 拆成 SELECT COUNT(*) FROM t WHERE a=1 UNION ALL SELECT COUNT(*) FROM t WHERE b=2——这算的是两个独立计数之和，不是“满足任一条件的总行数”，语义已改变。
- 原查询
SELECT COUNT(*) FROM orders WHERE status = 'shipped' OR user_id = 1001统计的是所有满足任一条件的记录总数 - 拆成 UNION ALL 后：
SELECT COUNT(*) ... WHERE status='shipped'+SELECT COUNT(*) ... WHERE user_id=1001，会重复计算 status='shipped' AND user_id=1001 的行 - 若改用
SELECT COUNT(*) FROM (SELECT id FROM orders WHERE status='shipped' UNION SELECT id FROM orders WHERE user_id=1001) t，虽语义正确，但触发临时表 + 去重排序，性能可能比原 OR 更差
聚合场景下优先验证是否真需要 OR
很多标称“带 OR 的聚合查询”，实际是业务逻辑误写。例如统计“已发货或高价值客户订单数”，常被写成 WHERE status = 'shipped' OR is_vip = 1，但若字段有索引且数据分布倾斜，优化器可能仍走全表扫描。
- 先用
EXPLAIN看原查询type：如果是ALL，说明已失效；如果是index_merge，说明 MySQL 正在尝试合并索引——此时改 UNION 反而破坏优化器路径 - 检查字段选择性：
SELECT COUNT(*) FROM t WHERE status = 'shipped'和SELECT COUNT(*) FROM t WHERE user_id = 1001各返回多少行？如果一个返回 10 行、另一个返回 500 万行，OR 条件本质由后者主导，应优先优化那个分支 - 考虑用覆盖索引把聚合“下推”到索引层，例如
CREATE INDEX idx_status_uid ON orders(status, user_id)，配合SELECT COUNT(*) FROM orders WHERE status = 'shipped' OR user_id = 1001，有时能触发 index_merge union 且避免回表
真要拆聚合，必须用派生表 + 外层聚合，且代价清晰
仅当确认各 OR 分支互斥（如 status IN ('shipped','cancelled')，且业务约束保证不会同时为真），才可安全拆。否则必须在外层重新聚合，并接受额外开销。
- 正确写法示例（互斥场景）：
SELECT COUNT(*) FROM ( SELECT id FROM orders WHERE status = 'shipped' UNION ALL SELECT id FROM orders WHERE status = 'cancelled' ) AS t;
- 非互斥但需精确结果：
SELECT COUNT(*) FROM ( SELECT id FROM orders WHERE status = 'shipped' UNION SELECT id FROM orders WHERE user_id = 1001 ) AS t;
注意这里必须用UNION（去重），UNION ALL会导致重复计数 - 带 GROUP BY 的复杂情况（如按月统计 shipped/cancelled 订单数），不应拆 OR，而应改用条件聚合：
SELECT YEAR(created_at), COUNT(CASE WHEN status = 'shipped' THEN 1 END), COUNT(CASE WHEN status = 'cancelled' THEN 1 END) FROM orders GROUP BY YEAR(created_at)
最易被忽略的一点：聚合 + OR 的慢，往往不是 OR 本身的问题，而是缺少覆盖索引导致大量回表。先加 EXPLAIN，再看 Extra 里有没有 Using temporary; Using filesort 或 Using where; Using index —— 前者说明结构问题严重，后者才是索引生效的标志。盲目拆 UNION ALL 只会让问题更隐蔽。
