子查询中直接用STRING_AGG报错，因STRING_AGG是聚合函数，必须配合GROUP BY使用；未分组时SQL拒绝执行，报“aggregate function calls cannot be nested”。正确写法是在子查询内添加GROUP BY（如GROUP BY true）或改用LATERAL关联确保每行独立聚合。
子查询里用 STRING_AGG 为什么报错“不可聚合”？
直接在子查询中写 STRING_AGG(column, ',') 报错 ERROR: aggregate function calls cannot be nested，是因为子查询本身没分组，而 STRING_AGG 是聚合函数，SQL 不允许在未分组的上下文中嵌套聚合——哪怕它藏在子查询里。
真正能跑通的写法是：子查询必须带 GROUP BY，且外层不能对子查询结果再做聚合（比如再套一层 STRING_AGG）。常见误操作是把子查询当表达式用，却忘了它本质是个结果集。
- 正确姿势：子查询返回单列单行（靠
GROUP BY+ 聚合保证），外层当标量用 - 错误姿势：
(SELECT STRING_AGG(name, ',') FROM orders WHERE user_id = u.id)—— 缺少GROUP BY，PostgreSQL 会直接拒绝 - 兼容写法（PostgreSQL）：子查询末尾加
GROUP BY true强制单组，但仅限子查询内无其他分组需求时用
PostgreSQL 中一对多打平的标准写法
假设用户表 users 和订单表 orders 是一对多，想查每个用户及其所有订单号拼成的字符串，最稳的方式是用 LATERAL 或主表左连接后分组。
推荐用 LEFT JOIN LATERAL，避免主表因一对多被意外放大：
SELECT u.id, u.name, COALESCE(o.order_list, '') AS order_list FROM users u LEFT JOIN LATERAL ( SELECT STRING_AGG(o2.order_no::text, ',') AS order_list FROM orders o2 WHERE o2.user_id = u.id ) o ON true;
-
LATERAL让子查询能引用外层u.id，且自然按主表每行执行一次 -
COALESCE防止无订单用户返回NULL - 注意类型：如果
order_no是数字，务必显式转::text，否则STRING_AGG会报错
MySQL 8.0+ 怎么等效实现？
MySQL 没有 LATERAL，但支持相关子查询 + GROUP_CONCAT，语法更直白，但性能需留意：
SELECT u.id, u.name, (SELECT GROUP_CONCAT(o.order_no SEPARATOR ',') FROM orders o WHERE o.user_id = u.id) AS order_list FROM users u;
- 这个子查询虽没写
GROUP BY，但 MySQL 允许在标量子查询中隐式按外层关联条件分组 - 必须用
SEPARATOR指定分隔符，不写默认是逗号，但显式写更安全 - 潜在坑：如果某用户有上千订单，
GROUP_CONCAT默认长度限制是 1024 字符，超长会被截断；需提前设SET SESSION group_concat_max_len = 1000000;
ORDER BY 在 STRING_AGG / GROUP_CONCAT 里怎么生效？
排序不是可选项，而是影响结果稳定性的关键。不加 ORDER BY 会导致每次查询顺序随机，尤其在分布式或并发环境下。
- PostgreSQL：
STRING_AGG(o.order_no::text, ',' ORDER BY o.created_at DESC) - MySQL：
GROUP_CONCAT(o.order_no ORDER BY o.created_at DESC SEPARATOR ',') - 注意：MySQL 的
ORDER BY必须写在SEPARATOR前，位置错会报语法错误 - 如果排序字段可能为
NULL，建议补上NULLS LAST（PG）或IS NULL判断（MySQL），否则NULL可能排最前干扰阅读
实际用的时候，最容易漏的是类型转换和长度限制——尤其是从 PostgreSQL 迁移到 MySQL 时，STRING_AGG 自动适配类型，而 GROUP_CONCAT 对数字字段会静默失败，必须手动转字符串。
