UNION后直接写GROUP BY会报语法错误，典型提示如“ERROR: syntax error at or near 'GROUP'”，因UNION是集合操作符，非完整查询主体，GROUP BY只能作用于单个SELECT结果集；必须用带别名的子查询包裹UNION结果才能正确聚合。
UNION后直接写GROUP BY会报什么错
会报语法错误，典型提示类似 ERROR: syntax error at or near "GROUP" 或 GROUP BY is not allowed here。因为 UNION 是集合操作符，不是单个查询主体，GROUP BY 只能作用于一个完整的 SELECT 语句结果集，不能跨在 UNION 后面直接挂载。
必须用子查询包裹UNION结果才能GROUP BY
正确做法是把整个 UNION ALL（或 UNION）语句作为子查询，再对外层做聚合。子查询必须带别名，否则所有主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）都会拒绝执行。
示例：
SELECT COUNT(*), status FROM ( SELECT status FROM orders_2024 UNION ALL SELECT status FROM orders_2025 ) AS combined GROUP BY status;
-
AS combined别名不可省，漏写会报错 - 优先用
UNION ALL：避免隐式去重干扰计数，尤其当字段类型不一致时，UNION的去重逻辑可能因隐式转换产生意外行为 - 列名以第一个
SELECT为准——后续分支即使写了AS xxx，外层聚合也必须用第一个定义的列名（如status），不能用order_status这类别名 - 如果第一个
SELECT用了表达式（如UPPER(name)），那结果列名就是UPPER(name)，聚合时得写GROUP BY UPPER(name)；建议统一加显式别名提升可读性
字段类型不一致会导致GROUP BY静默失败
两个 SELECT 中同序号列类型不兼容时，UNION 阶段可能隐式转换（MySQL较宽松），但到 GROUP BY 阶段，值无法比较就会跳过某些行，或返回空结果——没有报错，但统计不准。
应对方式：
- 显式转换类型：
SELECT id::TEXT, amount FROM sales UNION ALL SELECT CAST(order_id AS TEXT), total FROM orders - 补缺失字段时别依赖
NULL自动推断类型，写成NULL::VARCHAR或NULL::NUMERIC - PostgreSQL 会直接报错
UNION types text and integer cannot be matched，MySQL 可能“成功”但结果异常，务必验证
WHERE条件不下推，性能会崩
想查“近30天订单+退款总数”，如果只在外层加 WHERE dt >= CURRENT_DATE - 30，数据库得先把全量历史数据 UNION ALL 完再过滤，IO 和内存压力极大。
必须把条件下推到每个分支：
SELECT dt, amt FROM sales WHERE dt >= '2026-07-05' UNION ALL SELECT dt, amt FROM refunds WHERE dt >= '2026-07-05'
- 每个分支的
WHERE才能命中各自表的索引，合并后无法复用索引 -
ORDER BY和LIMIT也不能放在外层，必须塞进子查询内部，否则语法非法 - 如果某分支没加条件，等于主动放弃该表的索引能力
真正容易被忽略的不是语法，而是类型对齐和条件下推这两点——它们不会立刻报错，但会让结果出错或慢得离谱，查半天才发现是隐式转换或全表扫描拖垮了。
