如何优化SQL中带有OR条件的聚合查询_通过UNION ALL拆分逻辑提升速度-SQL-PHP中文网

UNION ALL 拆分对聚合查询基本无效，强行拆会出错或结果错误；必须先确认是否真需聚合，再决定能否拆分，且非互斥条件必须用 UNION 去重或条件聚合。

如何优化sql中带有or条件的聚合查询_通过union all拆分逻辑提升速度

直接结论：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 只会让问题更隐蔽。