group_concat被截断是因group_concat_max_len默认1024字节过小，需调大该参数并同步确保max_allowed_packet不小于它，注意utf-8多字节字符影响及端到端长度限制。
不是函数写错了，是数据库在底层硬性拦住了——每个聚合函数都有自己的“长度天花板”，超了就报错或静默丢数据。
MySQL 的 GROUP_CONCAT 默认只敢拼 1024 字节
它不报错、不警告，直接把后面的内容砍掉。你查 SELECT @@group_concat_max_len，大概率看到的是 1024。这不是 bug，是出厂设置。
- 会话级临时放开：
SET SESSION group_concat_max_len = 2097152（2MB，按业务最大预期 + 20% 设） - 必须同步检查
max_allowed_packet，它得 ≥ 上面那个值，否则拼完了也发不出去，报Packet for query is too large - UTF-8 下中文占 3–4 字节，
1024字节实际撑不了多少汉字；别用字符数去估算，要用LENGTH()算字节数 - 如果拼完还要再处理（比如
SUBSTRING()），得先确保GROUP_CONCAT本身没被截过，否则切的是残缺字符串
Oracle 的 LISTAGG 卡在 4000 字节硬限制
ORA-01489 就是它发出的求救信号。AL32UTF8 下一个中文算 3 字节，1334 个字就爆了——比想象中快得多。
-
ON OVERFLOW TRUNCATE是权宜之计，不是解法；它掩盖问题，下游拿到的仍是残缺数据 - 真要完整结果，得绕开
LISTAGG返回VARCHAR2的限制，改用：XMLAGG(XMLELEMENT(e, col) ORDER BY sort_col).GETCLOBVAL() -
ORDER BY必须写在WITHIN GROUP里，写在外面完全无效；很多人调了半天顺序，发现拼出来还是乱的，就是这个原因 -
NULL值默认跳过，不是丢了数据，是函数行为；想显式转成'(unknown)'，得包一层NVL(col, '(unknown)')
PostgreSQL 的 STRING_AGG 表面无限制，实则怕内存爆
它不像前两者有明确字节上限，但大结果会吃光 work_mem，触发磁盘落盘甚至 OOM。现象是查询变慢、连接中断，而不是直接报错。
- 先查当前配置：
SHOW work_mem；若聚合字段平均很长、行数又多，建议临时调高，比如SET LOCAL work_mem = '64MB' - 加
FILTER (WHERE col IS NOT NULL)避免空值干扰逻辑，也减少无效拼接 - 如果拼的是 JSON 或带逗号的文本，
STRING_AGG容易被分隔符污染；这时不如用ARRAY_AGG+ 应用层序列化，更可控 - 导出到 Excel 或传给老系统时，单格上限 32767 字符，再长也没用——长度控制得从数据库一直对齐到下游接收端
真正麻烦的从来不是“怎么拼得更长”，而是“谁来接住它”。数据库调完了，应用层字段还是 VARCHAR(1000)，或者 ORM 自动映射成短字符串，照样丢数据。别只盯着 SQL 调参，得端到端看住每一环。
