GROUP_CONCAT被截断是因group_concat_max_len默认值过小，需调大该参数并确保max_allowed_packet不小于它，同时注意端到端长度限制。
GROUP_CONCAT 默认只返回前 1024 字符，超出部分静默丢弃——这不是数据问题，是配置限制。
MySQL 中 GROUP_CONCAT 被截断怎么办？
现象很典型：拼出来的标签、路径、日志片段突然变短，结尾缺内容，但查询不报错。根本原因是 group_concat_max_len 默认值太小。
- 查当前值：
SELECT @@group_concat_max_len; - 会话级临时调大（推荐）：
SET SESSION group_concat_max_len = 2097152;（2MB） - 别设成
99999999这种魔数，按业务最大预期长度 + 20% 余量设即可 - 注意：该设置只对当前连接有效，应用层每次建立新连接都要重设，或在连接池初始化 SQL 里统一加
Oracle / PostgreSQL 用 LISTAGG 报 “字符串连接的结果太长”？
这是 Oracle 的硬限制：LISTAGG 返回 VARCHAR2，上限 4000 字节（CHAR 模式下是 4000 字符）。PostgreSQL 的 STRING_AGG 虽无硬限制，但大结果仍可能触发内存溢出。
- Oracle 替代方案：
XMLAGG+GETCLOBVAL()，返回CLOB类型：XMLAGG(XMLELEMENT(e, col_name || ',').EXTRACT('//text()') ORDER BY sort_col).GETCLOBVAL() - PostgreSQL 更稳妥：
STRING_AGG(col_name, ', ') FILTER (WHERE col_name IS NOT NULL)，配合work_mem调整 - 别依赖
LISTAGG(... ON OVERFLOW TRUNCATE)，它只是掩盖问题，不是解决
为什么调大长度后还报错？检查这三个地方
调了 group_concat_max_len 或换了 XMLAGG 还出错，大概率卡在底层通信或内存环节。
-
max_allowed_packet必须 ≥group_concat_max_len，否则 MySQL 服务端拼完也发不出去，报Packet for query is too large - 聚合字段含大量空格或不可见字符？先
TRIM()或REPLACE(col, ' ', '')再拼，能显著减小实际字节数 - GROUP BY 字段本身过长（比如 TEXT 列直接分组），会导致哈希键膨胀，跟拼接无关——改用
SUBSTRING(col, 1, 255)分组更安全
真正麻烦的不是“怎么拼得更长”，而是“拼出来之后谁来消费”。如果下游应用接收字段仍是 VARCHAR(1000)，再长也没用；如果导出到 Excel，单格上限 32767 字符，超了照样丢。留个心眼：长度控制要端到端对齐，不能只盯数据库一侧。
