STRING_AGG结果被截断主因是类型隐式降级或SSMS客户端限制；输入类型决定返回上限（如INT→NVARCHAR(4000)），超长则静默截断；需显式转NVARCHAR(MAX)、查源字段类型、禁用SSMS字符剪切并验证真实长度。
STRING_AGG结果被截断，90%不是函数问题，而是类型推导或客户端限制导致的隐式降级。
输入表达式类型决定返回上限
SQL Server 会根据 STRING_AGG 第一个参数的类型，硬性映射返回类型：输入是 VARCHAR(100) → 结果是 VARCHAR(8000)；输入是 INT → 结果强制为 NVARCHAR(4000)。一旦拼接总长超限，就静默截断（不报错）或触发 String or binary data would be truncated。
- 查源字段类型：
SELECT DATA_TYPE, CHARACTER_MAXIMUM_LENGTH FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME = 'name' - 别直接写
STRING_AGG(id, ',')（id是INT），改用STRING_AGG(CAST(id AS VARCHAR(20)), ',') - 要无上限输出，必须让输入是
NVARCHAR(MAX)或VARCHAR(MAX)，例如：STRING_AGG(CONVERT(NVARCHAR(MAX), name), ',') - 注意：NULL 值默认跳过，但空字符串
''会被保留，可能造成'a,,b'这类异常，可用NULLIF(name, '')统一处理
SSMS 显示截断 ≠ 实际截断
在 SSMS 网格视图中看到结果只有前 4000 或 65535 字符，大概率是客户端设置限制，不是数据真丢了。
- 验证真实长度：
DECLARE @out NVARCHAR(MAX) = (SELECT STRING_AGG(name, ',') FROM users); SELECT LEN(@out), DATALENGTH(@out); - 若
LEN()明显偏小，说明中间某步隐式转成了NVARCHAR(4000) - 禁用 SSMS 截断：工具 → 选项 → 查询结果 → SQL Server → 常规 → 取消勾选“将超出此数量的字符剪切”
- 导出 CSV 时仍被砍？改用“结果以文本显示”（Ctrl+T）再复制，或用
SELECT @out FOR XML PATH('')避免网格渲染干扰
GROUP BY + STRING_AGG 中的类型对齐陷阱
当 SELECT 列表里混用窄类型字段（如 INT、DATETIME）和 STRING_AGG，SQL Server 优化器可能把整个结果集按最窄列对齐，间接导致聚合结果被压缩。
- 错误写法：
SELECT id, STRING_AGG(name, ',') FROM t GROUP BY id（id是INT，可能拖累STRING_AGG类型推导） - 安全写法：显式控制聚合字段类型，并隔离输出，例如：
SELECT id, STRING_AGG(CONVERT(NVARCHAR(MAX), name), ',') FROM t GROUP BY id - 更稳妥：先用 CTE 或子查询预处理，确保输入已是
MAX类型，再聚合 - 避免在
ORDER BY或WITHIN GROUP中使用非确定性函数（如NEWID()），否则排序不稳定，可能漏掉部分值而不报错
DISTINCT 和 WITHIN GROUP 加剧截断风险
STRING_AGG(DISTINCT ...) 和 WITHIN GROUP (ORDER BY ...) 都会触发额外内存操作，大数据量下容易因资源不足提前终止，导致结果偏短且无声失败。
- 去重本身不保证顺序，必须配
WITHIN GROUP，但二者叠加会使 SQL Server 执行两次排序（去重哈希 + 排序），开销翻倍 - 若目标列无索引，DISTINCT 性能急剧下降；建议建非聚集索引：
CREATE NONCLUSTERED INDEX IX_t_value ON t(value) - 实测发现：100 万行中重复率低于 5%，用
STRING_AGG(DISTINCT ...)比先SELECT DISTINCT再聚合慢 3 倍以上 - 临时救急：加
OPTION (RECOMPILE)强制生成新执行计划，避开旧计划缓存导致的内存误判
真正难调试的不是语法错误，而是那些既不报错、也不警告、只悄悄少返回几百个字符的情况——它们往往藏在类型隐式转换、SSMS 设置、或执行计划缓存里。
