Redshift查询svl_statementtext报LISTAGG超65535限制但长度远低于阈值

该问题是Amazon Redshift下使用LISTAGG拼接svl_statementtext字段的典型问题，触发原因集中在两点：

• 分组维度缺失：svl_statementtext是集群所有计算切片独立存储查询文本分片的系统表，仅按pid,xid分组会遗漏切片/节点维度，同一份查询的文本分片会在每个切片存一份，全局聚合阶段会把所有切片的同分组分片全部纳入拼接，相当于重复拼接N次（N为集群切片总数），最终长度触达65535上限。
  之前统计总字节数得到最大值仅2962的结果不准，是因为SUM(OCTET_LENGTH())的局部聚合在单切片上执行，仅统计了单切片内的分片长度，没有计算跨切片重复拉取的部分。
• 引擎校验bug：Redshift旧版本的LISTAGG长度校验基于UTF-8字符数而非字节数，若待拼接的文本分片包含截断产生的\0空字符，引擎会错误计算字符串长度，提前触发超限报错。

1. 先校验分组是否存在异常多的分片，正常单查询的文本分片数在几十行以内，如果结果出现数百上千行的分组，即可确认是维度缺失导致的重复聚合：

SELECT pid,xid, COUNT(*) AS fragment_count, MIN(starttime) AS starttime
FROM svl_statementtext
WHERE starttime >= '2022-06-27 10:00:00'
GROUP BY pid,xid
ORDER BY fragment_count DESC
LIMIT 10;

2. 排查是否存在包含空字符的异常分片：

SELECT pid,xid, COUNT(*) AS invalid_fragment_num
FROM svl_statementtext
WHERE starttime >= '2022-06-27 10:00:00'
AND POSITION(chr(0) IN "text") > 0
GROUP BY pid,xid;

1. 补全分组维度，先对跨切片的重复分片去重再聚合，不要使用pg_catalog下的内部listagg实现，调用公开的函数即可：

WITH dedup_fragment AS (
    SELECT DISTINCT pid, xid, userid, "sequence", "text", starttime
    FROM svl_statementtext
    WHERE starttime >= '2022-06-27 10:00:00'
)
SELECT 
    pid,
    xid, 
    userid,
    MIN(starttime) AS starttime, 
    LISTAGG(RTRIM("text"), '') WITHIN GROUP(ORDER BY "sequence") AS query_statement 
FROM dedup_fragment
GROUP BY pid,xid,userid;

2. 若集群版本为1.0.25762及以上，可增加溢出截断参数，避免单查询本身长度超限时直接报错：

WITH dedup_fragment AS (
    SELECT DISTINCT pid, xid, userid, "sequence", "text", starttime
    FROM svl_statementtext
    WHERE starttime >= '2022-06-27 10:00:00'
)
SELECT 
    pid,
    xid, 
    userid,
    MIN(starttime) AS starttime, 
    LISTAGG(RTRIM("text"), '' ON OVERFLOW TRUNCATE '...' WITHOUT COUNT) 
        WITHIN GROUP(ORDER BY "sequence") AS query_statement 
FROM dedup_fragment
GROUP BY pid,xid,userid;

3. 旧版本不支持溢出截断参数时，可先按sequence排序过滤前N个分片再拼接，或通过自定义字符串聚合UDF绕过LISTAGG的长度限制。

内容的提问来源于stack exchange，提问作者SimonB