SQL Server 2017+合法去重写法为STRING_AGG(DISTINCT col, sep)，DISTINCT须紧贴函数名后、单表达式前；空字符串参与去重而NULL被跳过；排序必须用WITHIN GROUP(ORDER BY)，且可能触发两次排序影响性能。
SQL Server 2017+ 直接支持 STRING_AGG(DISTINCT col, sep)，但语法位置、NULL 处理和排序写法稍有不慎就会报错或结果异常——不是所有看着像去重的写法都真能生效。
STRING_AGG(DISTINCT ...) 的合法写法长什么样
必须把 DISTINCT 紧贴在函数名后、第一个括号内，且只作用于**单个表达式**；分隔符和 WITHIN GROUP 都不能套在 DISTINCT 外面。
- ✅ 正确：
STRING_AGG(DISTINCT name, ',') - ✅ 正确（带表达式）：
STRING_AGG(DISTINCT LOWER(name), ', ') - ❌ 错误：
STRING_AGG(DISTINCT(name), ',')（括号多了一层） - ❌ 错误：
STRING_AGG(DISTINCT name, ',') WITHIN GROUP (ORDER BY name)（WITHIN GROUP缺失） - ❌ 错误：
STRING_AGG(DISTINCT name, ',') ORDER BY name（外部ORDER BY不影响拼接顺序）
NULL 和空字符串 '' 会悄悄破坏去重效果
STRING_AGG 默认跳过 NULL，但把空字符串 '' 当作有效值参与去重和拼接——这会导致结果里冒出多余逗号，比如 'apple,,orange'。
- 过滤空值：
WHERE supplier IS NOT NULL AND supplier != '' - 把
''当NULL处理：STRING_AGG(DISTINCT NULLIF(supplier, ''), ';') - 把
NULL当普通值（如统一标为'N/A'）：STRING_AGG(DISTINCT COALESCE(supplier, 'N/A'), ';') - 大小写敏感去重？加
LOWER()：STRING_AGG(DISTINCT LOWER(supplier), ';')
排序必须用 WITHIN GROUP，且它影响性能
想让拼接结果按字母或时间顺序排列，只能靠 WITHIN GROUP (ORDER BY ...)，而且这个子句必须紧跟在 STRING_AGG(...) 括号后面、分号之前。
- ✅ 正确：
STRING_AGG(DISTINCT name, ', ') WITHIN GROUP (ORDER BY name) - ⚠️ 性能注意：SQL Server 2019 中，
DISTINCT+WITHIN GROUP可能触发两次排序（先哈希去重，再排序），大数据量下明显变慢 - 优化建议：被聚合字段（如
name）上建非聚集索引，例如CREATE NONCLUSTERED INDEX IX_orders_supplier ON orders(supplier) - 若数据超百万行且对性能敏感，可改用 CTE 预处理：
SELECT DISTINCT group_id, supplier FROM orders再外层GROUP BY+STRING_AGG
GROUP BY 粒度不一致是隐形杀手
常见错误是 GROUP BY 字段没覆盖所有非聚合列，或者去重逻辑和求和/计数等操作不在同一分组层级下。
- ❌ 错误：
SELECT product, SUM(qty), STRING_AGG(supplier, ';') FROM orders GROUP BY product→supplier未去重，且SUM(qty)和拼接未共享相同逻辑分组粒度 - ✅ 正确：
SELECT product, SUM(qty), STRING_AGG(DISTINCT supplier, ';') FROM orders GROUP BY product（前提是product是唯一分组依据） - 更稳妥做法：确保所有非聚合字段都出现在
GROUP BY中，避免隐式依赖或执行计划歧义
真正容易被忽略的是 JOIN 后的数据膨胀——如果在多表关联后直接 STRING_AGG(DISTINCT ...)，而没检查关联是否引入了重复行，去重结果可能比预期少（因为重复被抹掉了），也可能比预期多（因 JOIN 放大了原始行数）。动手前先 SELECT TOP 10 * 看一眼中间结果，比反复调语法更省时间。
