GROUP_CONCAT结果被截断需调大group_concat_max_len参数；默认1024字节，超长静默丢弃，可SET SESSION临时修改或配置my.cnf永久生效，并注意UTF-8多字节字符影响及max_allowed_packet限制。
GROUP_CONCAT结果被截断怎么办？
MySQL默认会把GROUP_CONCAT结果限制在1024字符内，超出部分直接丢弃——不是报错，而是静默截断，容易漏查。根本原因是系统变量group_concat_max_len设得太小。
临时生效（当前会话）：SET SESSION group_concat_max_len = 10000;
永久生效（需有权限改配置）：在my.cnf里加一行group_concat_max_len = 10000，然后重启MySQL。
注意：这个值是字节长度，不是字符数；如果字段含UTF-8多字节字符（比如中文），实际能拼接的字符数会更少。
如何在SELECT里动态控制单次拼接长度？
GROUP_CONCAT本身不支持“截取前N个字符”这种逻辑，但可以用SUBSTRING包裹它来实现：
SELECT SUBSTRING(GROUP_CONCAT(name SEPARATOR ', '), 1, 50) AS names FROM users GROUP BY dept;
这样拼完再切，但要注意：如果原始拼接结果已因group_concat_max_len被截断，SUBSTRING就只能切那个已被砍过的字符串。
常见误用：
❌ GROUP_CONCAT(SUBSTRING(name, 1, 10)) —— 这是对每个name先截10字符再拼，不是控制最终结果长度
✅ 正确顺序是先GROUP_CONCAT，再SUBSTRING
GROUP_CONCAT和ORDER BY一起用时的长度陷阱
加上ORDER BY不会改变长度限制，但会影响截断位置——比如按时间倒序排，被截掉的往往是最新几条记录，而不是随机丢。
实操建议：
• 如果业务依赖拼接结果的完整性（比如导出名单），必须提前确认group_concat_max_len足够大
• 若不确定每组最大可能长度，可先用CHAR_LENGTH(GROUP_CONCAT(...))查最长组，再反推需要设多大
• 避免在子查询里嵌套GROUP_CONCAT后又做字符串操作，MySQL 5.7+对这类嵌套的优化较弱，性能易抖动
替代方案：为什么有时候该放弃GROUP_CONCAT？
当拼接内容超过几万字符、或需要精确控制分隔符/去重/空值处理时，GROUP_CONCAT会变得不可靠：
• 它不能跳过NULL值（除非显式写IFNULL(name, '')）
• 不支持条件拼接（比如只拼status=1的记录，得靠CASE WHEN绕）
• 在JSON场景下，不如JSON_ARRAYAGG（MySQL 5.7+）稳定，后者天然支持嵌套、类型保持、无长度硬限制
简单判断标准：如果拼接结果要交给下游做解析、或长度波动大、或含特殊字符（逗号、反斜杠），优先考虑应用层聚合或JSON_ARRAYAGG。
