ORA-01489是Oracle对LISTAGG硬性限制4000字节所致，并非语法错误；根本解法是改用XMLAGG+GETCLOBVAL返回CLOB，或12cR2+使用ON OVERFLOW TRUNCATE显式截断。
LISTAGG 或 STRING_AGG 超长报错（ORA-01489 / “result too long”）
这不是写法错误，而是数据库对聚合结果的硬性长度限制：Oracle LISTAGG 默认上限 4000 字节，PostgreSQL STRING_AGG 受 work_mem 和目标列类型约束，MySQL GROUP_CONCAT 默认 1024 字节（由 group_concat_max_len 控制）。一旦拼接后超限，Oracle 直接报 ORA-01489，PostgreSQL 可能静默截断或报错，MySQL 则丢弃超出部分。
实操建议：
- Oracle 12cR2+ 必须显式加
ON OVERFLOW TRUNCATE，例如：LISTAGG(content, ' | ') WITHIN GROUP (ORDER BY id) ON OVERFLOW TRUNCATE '…' - PostgreSQL 改用
STRING_AGG(content::text, ' | ' ORDER BY id)，并确保content列本身不是BYTEA；若原始为CLOB或含二进制前缀，先CONVERT_FROM(content, 'UTF8') - MySQL 动态调大阈值：
SET SESSION group_concat_max_len = 1000000;，再执行GROUP_CONCAT(content SEPARATOR ' | ')；注意该设置不跨会话，生产环境建议在应用层初始化 SQL 中统一设置
TEXT/CLOB 字段直接进聚合函数导致隐式转换失败
在 Oracle、SQL Server 或旧版 MySQL 中，把 TEXT、CLOB、ntext 类型字段直接塞进 LISTAGG 或 STRING_AGG，常触发类型不匹配或函数不可用错误。例如 SQL Server 报 Msg 306，MySQL 5.7 对 LONGTEXT 的 GROUP_CONCAT 可能返回空或乱码。
实操建议：
- Oracle：用
TO_CLOB()包裹子查询结果，例如：SELECT TO_CLOB(LISTAGG(NVL(text_col, ''), ' | ') WITHIN GROUP (ORDER BY id)) FROM t - SQL Server：必须先
CAST或CONVERT为NVARCHAR(MAX)，再进STRING_AGG（2017+）或FOR XML（旧版），例如：STRING_AGG(CAST(content AS NVARCHAR(MAX)), N' | ') WITHIN GROUP (ORDER BY id) - MySQL：避免对
LONGTEXT直接GROUP_CONCAT，先用SUBSTRING(content, 1, 5000)截断再聚合，或改用应用层拼接
聚合后前端显示重复省略号或宽度失准
SQL 层做了截断（如 ON OVERFLOW TRUNCATE '…'），但前端框架又按字符数二次截断，结果变成“内容…”，甚至“内容……”，或者 CSS 计算宽度时把省略号当 1 字符，而实际是 UTF-8 三字节符号，造成布局错位。
实操建议：
- SQL 层只做「是否截断」判断，不拼省略号——让前端统一处理，例如 Oracle 返回完整 CLOB，由 Java/Python 按需
substring(0, 200) + "..." - 若必须 SQL 出省略号，MySQL 用
CHAR_LENGTH()判断，PostgreSQL 用CHAR_LENGTH()配合LEFT()，SQL Server 用LEN()（非DATALENGTH），全部对齐「字符单位」 - 所有数据库中，省略号统一用 Unicode 字符
N'…'（U+2026），而非三个英文点'...'，避免字体渲染差异和宽度误判
聚合大文本时性能崩盘或内存溢出
对千万级表的 TEXT 字段做 GROUP_CONCAT 或 STRING_AGG，极易触发临时表爆内存、OOM Killer 杀进程，尤其当分组键基数低（如全表只一个 group）、单个分组内文本行数过万时。
实操建议：
- 先过滤再聚合：用
WHERE严格限定参与聚合的数据范围，避免GROUP BY前扫描全量大字段 - 分段聚合：用
WITH RECURSIVE（PostgreSQL/MySQL 8.0+）或GENERATE_SERIES拆分主键区间，每批聚合 1 万行，最后合并结果 - 拒绝在视图里做聚合：视图定义中包含
STRING_AGG等函数，会导致每次查询都重算，且无法走索引；应改为物化中间表 + 定时刷新
ON OVERFLOW，PostgreSQL 依赖 work_mem 配置，MySQL 纯靠调参和截断。最容易被忽略的是——你写的聚合语句在测试库跑通了，上线后因数据量翻倍或字符集变更（比如新增 emoji），立刻触发截断逻辑失效或内存告警。 
