UNION ALL要求列数、顺序和数据类型严格一致，明细与聚合查询拼接时需显式对齐字段、用NULL或CAST补全、添加统一标识列，并将ORDER BY置于末尾；聚合侧应避免误加GROUP BY导致多行。
UNION ALL 连接明细与聚合查询时，列数和数据类型必须严格一致
直接 SELECT * 的明细表和 SELECT COUNT(*), SUM(amount) 这类聚合结果拼 UNION ALL 会报错：列数不匹配或类型隐式转换失败。核心是让两边 SELECT 返回完全相同的字段结构——不是“语义相同”，而是“个数、顺序、类型”三者都对齐。
实操建议：
- 明细侧所有字段显式列出，聚合侧用
NULL或占位值补全缺失列（如id、name），并确保类型兼容（例如NULL::TEXT或CAST(NULL AS VARCHAR)） - 聚合侧的统计字段（如
SUM(amount)）需在明细侧对应位置也提供（哪怕填amount原值），否则无法对齐 - 加一个标识列（如
'detail'/'total'）便于后续区分，且该列两边都要有、类型一致（推荐用CHAR(6)或TEXT）
ORDER BY 必须放在整个 UNION ALL 查询末尾，且只能引用列名或序号
UNION ALL 是集合操作，中间每个子查询不能带 ORDER BY（除非配合 LIMIT 或窗口函数，但此时已非纯集合场景）。想让总计行固定在最后，必须在外层再套一层查询，或直接在最终 UNION ALL 后加 ORDER BY。
常见错误现象：ORDER BY 放在第二个子查询后 → 报语法错误；用别名排序但未在 SELECT 列表中出现 → 报“column does not exist”。
实操建议：
- 用列序号排序最稳妥，例如
ORDER BY 10 DESC（假设第 10 列是标识字段row_type） - 若按别名排序，必须在
SELECT中显式给出该别名，如'detail' AS row_type，然后写ORDER BY row_type - 总计行通常希望置底，可设
'total'的字典序大于'detail'，或用CASE WHEN row_type = 'total' THEN 1 ELSE 0 END控制顺序
聚合查询需用 GROUP BY () 或无分组聚合，避免意外多行
写 SELECT COUNT(*), SUM(amount) FROM orders 没问题，但一旦不小心加了 GROUP BY user_id，就会返回多行总计——这不符合“单行总计 + 多行明细”的预期结构，反而造成重复或错位。
使用场景：仅当你要为每个分组单独出一个总计行（比如每部门一个汇总+其下属员工明细），才需要 GROUP BY；否则，纯粹的全局总计必须去掉 GROUP BY，或明确写成 GROUP BY ()（PostgreSQL 支持，其他数据库可用 GROUP BY 1=1 等等效写法）。
实操建议：
- 确认是否真需要分组总计；若不需要，删掉
GROUP BY，或改用GROUP BY ()显式表达“空分组” - MySQL 8.0+ 和 SQL Server 支持
GROUP BY ()，旧版 MySQL 可用SELECT COUNT(*), SUM(amount) FROM (SELECT 1) t, orders强制单行（不推荐，仅作兼容备选） - 注意
COUNT(*)在空表时返回0，而COUNT(column)返回NULL，聚合侧统一用COUNT(*)更可控
性能影响：UNION ALL 本身无排序开销，但大结果集可能触发临时表或内存溢出
UNION ALL 不去重、不排序，理论上比 UNION 快很多。但把上万行明细和一行总计硬拼在一起，会导致结果集变大，客户端或驱动可能因缓冲区不足而截断、报错（如 Python 的 psycopg2 遇到超长结果集默认限制）。
性能/兼容性影响：
- 数据库层一般无压力，但应用层处理时要注意：一次性 fetch 所有行可能吃光内存，建议流式读取（
cursor.iterate()或分页模拟） - 某些 BI 工具（如 Tableau、Power BI）对含混合语义（明细+总计）的结果集解析异常，容易把总计行当成普通明细参与计算
- 替代思路：用窗口函数（如
SUM(amount) OVER()）在明细行旁附带总计列，更高效且语义清晰；只有强需求“物理拼成两段结果”时才用UNION ALL
真正难的不是写出来，而是让总计行不出现在中间、不被 BI 工具误读、不在大数据量下崩掉连接——这些细节往往在测试环境看不出来，上线后才暴露。
