group_concat在mysql中用于多行合并，但默认1024字符限制易致静默截断，须set session group_concat_max_len调大，并配合ifnull处理null、order by保证顺序、separator指定分隔符。
不能直接在 UPDATE 的 SET 子句里拼接多行结果，必须用子查询聚合后再赋值；不同数据库的语法和限制差异极大，写错会报错或静默截断。
MySQL 中用 GROUP_CONCAT 需防截断和空值
GROUP_CONCAT 是 MySQL 里最常用的多行合并函数，但它默认只返回最多 1024 字符，超长部分会被无声截掉。你得先调大 group_concat_max_len，否则 UPDATE 看似成功，实际字段内容不全。
- 执行前加：
SET SESSION group_concat_max_len = 10000;（临时生效，连接级） -
GROUP_CONCAT自动跳过NULL值，如需保留字面量'NULL'，得包一层：GROUP_CONCAT(IFNULL(val, 'NULL') SEPARATOR ',') - 子查询必须只返回一行一列，所以 WHERE 条件要能唯一绑定到主表当前行，比如
WHERE o.user_id = u.id - 错误写法：
UPDATE users SET order_list = order_list + (SELECT GROUP_CONCAT(...))——order_list是单值字段，不支持字符串加法运算，会报错或逻辑异常
正确示例：
UPDATE users u SET order_list = ( SELECT GROUP_CONCAT(o.order_id SEPARATOR ';') FROM orders o WHERE o.user_id = u.id );
PostgreSQL 中必须用 UPDATE ... FROM，不能嵌套 STRING_AGG
PostgreSQL 不允许在 SET 后直接跟聚合函数，STRING_AGG 必须放在 FROM 子句的派生表里，再通过 JOIN 关联更新。漏掉 ORDER BY 会导致每次结果顺序不一致，这是生产事故高发点。
- 必须显式写
ORDER BY，例如：STRING_AGG(order_id::TEXT, ',' ORDER BY created_at) - 空值默认被跳过，想显示为字符串
'NULL'，要用COALESCE(order_id::TEXT, 'NULL') - 别名不能省——派生表必须有别名（如
t2），否则语法报错 - WHERE 条件必须严格匹配，比如
u.id = t2.user_id，否则可能漏更新或误更新
正确示例：
UPDATE users u SET order_list = t2.list FROM ( SELECT user_id, STRING_AGG(order_id::TEXT, ',' ORDER BY id) AS list FROM orders GROUP BY user_id ) t2 WHERE u.id = t2.user_id;
SQL Server 2017+ 用 STRING_AGG，旧版本靠 FOR XML
SQL Server 2017 起支持 STRING_AGG，行为接近 PostgreSQL，但语法更宽松：可以出现在子查询中，不过仍建议用 FROM 方式提升可读性和稳定性。2016 及更早版本只能用 FOR XML + STUFF 组合，写法冗长且易出错。
- 用
STRING_AGG时，ORDER BY是可选的，但不写就等于放弃顺序控制，风险同 PostgreSQL -
FOR XML方式需额外处理开头多余逗号，常用STUFF(..., 1, 1, '')去掉第一个分隔符 - 所有字符串类型参与拼接前，必须显式转成
varchar或nvarchar，否则隐式转换可能失败
2017+ 示例：
UPDATE u SET order_list = agg.list FROM users u INNER JOIN ( SELECT user_id, STRING_AGG(CAST(order_id AS VARCHAR), ',') WITHIN GROUP (ORDER BY id) AS list FROM orders GROUP BY user_id ) agg ON u.id = agg.user_id;
跨数据库通用陷阱：NULL、长度、排序、子查询引用
真正踩坑的地方往往不是语法本身，而是这些细节：聚合结果含 NULL 时表现不一致；默认长度限制在不同数据库里数值不同（MySQL 1024、PostgreSQL 默认无上限但受内存影响）；没写 ORDER BY 导致结果不可重现；还有最隐蔽的——子查询里不小心又查了正在更新的表，触发 “target table in FROM clause” 类错误。
如果你的业务要求强一致性，比如订单列表必须按创建时间升序拼接、且不能丢任何一条，那光写对语法不够，还得验证聚合结果是否完整、顺序是否稳定、NULL 是否被合理处理。
