GROUP_CONCAT返回NULL或空主因是JOIN无匹配导致整行消失，或被聚合字段全为NULL而默认跳过；应改用LEFT JOIN、显式IFNULL兜底、检查GROUP BY完整性、调大group_concat_max_len防截断。
GROUP_CONCAT 在 INNER JOIN 后返回空或 NULL 怎么办
根本原因不是函数坏了，而是 JOIN 没匹配上，或者被聚合字段全为 NULL —— GROUP_CONCAT 默认跳过 NULL 值，若某组内所有 product_name 都是 NULL，结果就是空字符串；若整组记录因 INNER JOIN 失败被过滤掉，那这行压根不会出现在结果里。
实操建议：
- 把
INNER JOIN换成LEFT JOIN，先确认主表记录是否完整保留 - 在
GROUP_CONCAT内显式兜底：用IFNULL(t2.name, '未命名')或COALESCE(t2.name, '') - 检查
GROUP BY字段是否包含所有非聚合列（比如多表时漏写了t1.id） - 确认关联字段类型一致（如
INT对VARCHAR会导致隐式转换失败，静默无匹配）
STRING_AGG 在 PostgreSQL 中拼出来全是 NULL
STRING_AGG 本身不排斥 NULL，它会跳过单个 NULL 值；但当某组所有值都是 NULL 时，它返回的是 NULL 而非空字符串——这是最常踩的坑，上游应用一判空就崩。
安全写法必须加 COALESCE：
SELECT c.category_name, COALESCE(STRING_AGG(p.product_name, ', '), '') AS products FROM category c LEFT JOIN product p ON c.id = p.category_id GROUP BY c.id, c.category_name;
其他要点：
- 排序必须写在函数内：
STRING_AGG(p.name, ', ' ORDER BY p.created_at)，外面的ORDER BY不影响拼接顺序 - PostgreSQL 9.0+ 支持
ORDER BY，旧版本得先子查询排好序再聚合 - 分隔符只能是字面量字符串，不能是字段或表达式（
SEPARATOR p.delim会报错）
拼接结果被截断却没报错，怎么排查
MySQL 的 GROUP_CONCAT 默认长度上限是 1024 字符，超长部分直接丢弃，不警告、不报错、不提示——你看到的“数据变短了”，大概率就是它干的。
快速验证和修复：
- 查当前限制：
SELECT @@group_concat_max_len; - 临时调大（当前会话有效）：
SET SESSION group_concat_max_len = 1000000; - 永久生效要改配置文件
my.cnf，加一行group_concat_max_len = 1000000并重启 MySQL - 注意：
GROUP_CONCAT返回类型是TEXT，但受该变量限制，不是字段定义长度问题
PostgreSQL 的 STRING_AGG 没这个硬限制，但大数据量下可能触发内存或 work_mem 设置瓶颈，需结合 EXPLAIN ANALYZE 观察实际执行开销。
跨数据库写法怎么尽量少改代码
没有银弹，但可以收敛差异点。核心是把拼接逻辑下沉到视图或中间层，避免 SQL 硬编码函数名。
如果必须兼容 MySQL 和 PostgreSQL：
- 分隔符统一用英文逗号，避免
SEPARATOR '、'这类 MySQL 特有写法 - NULL 处理统一前置：
COALESCE(col, '')（MySQL/PG 都支持），再传给聚合函数 - 排序逻辑不要依赖函数内
ORDER BY，改为子查询先排好序（虽然性能略差，但可移植） - 别指望
GROUP_CONCAT和STRING_AGG参数顺序一样：前者是expr SEPARATOR str，后者是expr, str，硬套必错
真正容易被忽略的是：MySQL 的 GROUP_CONCAT 在 GROUP BY 字段含 NULL 时，会把所有 NULL 值归为同一组；而 PostgreSQL 的 STRING_AGG 在对应场景下行为一致，但如果你用了 DISTINCT 或窗口函数混搭，NULL 处理逻辑可能突然翻车。
