怎样在SQL查询中同时展示明细与合计行？使用UNION ALL连接聚合结果
先说一个核心判断：直接用GROUP BY是无法同时显示明细和合计的，因为它会折叠原始行、丢失明细。必须用UNION ALL将明细查询与单行聚合查询拼接，并且要求字段数、类型、顺序严格一致，最后通过ORDER BY或辅助排序字段确保合计行稳稳地放在最底下。
为什么直接用 GROUP BY 无法同时显示明细和合计
道理其实很简单：GROUP BY 的本职工作就是把原始行折叠成分组聚合结果，一旦分组，原始明细自然就消失了。如果你想既保留每条记录，又额外加一行“总计”，那就必须把这两类数据当作不同来源拼在一起——这正是 UNION ALL 的典型应用场景。
如何用 UNION ALL 拼接明细与合计（以 PostgreSQL/MySQL 为例）
核心思路很清晰：左边查询原始明细，右边查询单行聚合，两者字段的数量、类型、顺序必须严格对齐。这里最常见的坑就是字段对不齐，或者类型隐式转换失败。
- 明细查询里所有字段都照常写，但合计行对应位置要填上占位值：比如用
NULL，或者类型兼容的默认值（数字字段可以用0，字符串可以用'总计'）。 - 合计行中，非聚合字段统一用
NULL或特定标识符（例如'合计'），聚合字段则用SUM()、COUNT()这些函数。 - 务必在最终结果后加上
ORDER BY来控制合计行的位置，确保它出现在末尾。SQL 本身并不保证UNION ALL的结果顺序，不加排序的话，合计行很可能混在中间。
来看一个具体示例（统计订单明细并追加一行总金额）：
SELECT order_id, product_name, amount FROM orders UNION ALL SELECT NULL, '合计', SUM(amount) FROM orders ORDER BY order_id NULLS LAST;
合计行字段类型不匹配导致报错怎么办
你可能会遇到这样的错误：ERROR: UNION types text and integer cannot be matched。这直接说明了问题：左右两边同位置的字段类型不兼容。PostgreSQL 在这方面尤其严格，MySQL 有时会自动转换，但依赖这种自动行为并不可靠。
- 解决方法是用
CAST或::进行显式类型转换。例如，把NULL转换成TEXT：CAST(NULL AS TEXT)。 - 如果明细行中的数值字段需要在合计行显示为文字（比如‘小计’），那也需要统一转换成字符串，避免类型冲突。
- 记住，不要依赖数据库的自动类型推断。哪怕两边都写
NULL，不同字段也可能被推断成不同类型，显式声明总是更稳妥。
合计行放在最底下但排序乱了？
需要警惕的是，UNION ALL 本身不保证顺序。即使你左边的查询结果是有序的，和右边一拼接，顺序就可能被打乱。唯一可靠的方式是在最终结果上明确使用 ORDER BY，并且这个排序要能有效区分明细行和合计行。
- 推荐加一个辅助排序字段：
SELECT ..., 1 AS sort_order FROM ... UNION ALL SELECT ..., 2 AS sort_order FROM ... ORDER BY sort_order, order_id。这样合计行就能稳稳垫底。 - 也可以利用
NULLS LAST（PostgreSQL）或IS NULL（MySQL）让NULL值排到最后，但这有个前提：明细字段本身确实不包含NULL值。 - 要避免只按普通列名排序而不控制合计行位置，否则合计行很可能卡在结果集的中间。
话说回来，真正麻烦的往往不是基础写法，而是当明细查询本身已经嵌套多层或者包含了窗口函数时，再在外面套一层 UNION ALL 很容易让逻辑变得脆弱。这时候，就该考虑使用 GROUPING SETS 或者在应用层进行汇总了。
