MySQL GROUP_CONCAT 截斷陷阱深度解析：group_concat_max_len 限制與解決方案

現象：靜默截斷無報錯

SELECT aid, GROUP_CONCAT(bid) FROM tbl GROUP BY aid LIMIT 1;
-- 返回 Warning: 1260 | 1 line(s) were cut by GROUP_CONCAT()

業務層無感知，導致下游數據不完整、統計偏差、對賬失敗。

根因：默認長度僅 1024 字節

SELECT @@global.group_concat_max_len;  -- 1024

當拼接結果超過此值，MySQL 直接截斷並拋出 Warning（非 Error），應用若未檢查 Warning 將不知情。

解決方案

1. 會話級臨時調大（推薦，無需重啟）

SET SESSION group_concat_max_len = 102400;  -- 100KB
-- 或
SET @@session.group_concat_max_len = 102400;

2. 全局永久生效（需配置文件）

[mysqld]
group_concat_max_len = 102400

修改後 service mysqld restart。

3. 進階用法：排序與自定義分隔符

SELECT 
    aid,
    GROUP_CONCAT(bid ORDER BY bid DESC SEPARATOR '|') AS bid_str
FROM tbl
GROUP BY aid;

最佳實踐清單

1. 預估長度：AVG(LENGTH(bid)) * COUNT(*) 估算單組大小，設為 2~3 倍餘量。
2. 監控截斷：慢查詢日誌記錄 Warning，或應用層檢查 SHOW WARNINGS。
3. 大數據集替代方案：超過 1MB 時建議應用層分批拉取、或使用 JSON_ARRAYAGG（5.7+）、導出文件處理。
4. 內存影響：過大值會增加線程內存消耗（sort_buffer_size、join_buffer_size 相關），避免設為 GB 級。