GROUP_CONCAT默认不排序，必须在函数内用ORDER BY显式指定顺序；需注意长度截断、数字字符串排序陷阱及时区问题，并可考虑窗口函数替代。
GROUP_CONCAT 默认不排序，必须显式加 ORDER BY
很多人写 GROUP_CONCAT(name) 发现结果顺序“乱”，其实是它默认按数据物理存储或扫描顺序拼接，**不保证任何逻辑顺序**。MySQL 的 GROUP_CONCAT 支持在函数内部直接写 ORDER BY，这是唯一可靠控制合并后字符串顺序的方式。
- 错误写法：
GROUP_CONCAT(name) ORDER BY name—— 这个ORDER BY是对整个分组结果集排序，不影响单个GROUP_CONCAT内部拼接顺序 - 正确写法：
GROUP_CONCAT(name ORDER BY name ASC)或GROUP_CONCAT(name ORDER BY create_time DESC, id ASC) - 注意：
ORDER BY必须写在括号内、逗号前，且只能引用当前 SELECT 中的列（或表达式），不能用别名（除非重复写原表达式）
排序字段类型不一致会导致隐式转换和意外顺序
如果排序字段是字符串但含数字前缀（如 "item1", "item10", "item2"），直接 ORDER BY field 会按字典序排成 item1,item10,item2。这不是 bug，是预期行为。
- 解决数字逻辑排序：用
ORDER BY CAST(SUBSTRING(field, 5) AS UNSIGNED)（假设前4位固定） - 更健壮方式：配合
LPAD补零，如ORDER BY LPAD(SUBSTRING(field, 5), 10, '0') - 时间字段注意时区：若列是
DATETIME但业务按 UTC 存储，而会话时区是 +08:00，ORDER BY created_at仍按原始值排序，无需额外转换
GROUP_CONCAT 长度截断是静默的，必须主动调大
MySQL 默认 group_concat_max_len = 1024，超长会被无声截断——你看到的只是前 N 个字符，后面内容丢了，还查不出错。
- 临时改（当前 session）：
SET SESSION group_concat_max_len = 1000000; - 永久改（需权限）：在
my.cnf加group_concat_max_len = 1000000 - 检查当前值：
SELECT @@group_concat_max_len; - 安全起见，建议在使用
GROUP_CONCAT的查询开头加SET SESSION group_concat_max_len = ...，避免依赖全局配置
替代方案：窗口函数 + 字符串聚合（MySQL 8.0+ / PostgreSQL）
如果需要更灵活的排序控制（比如按某字段排序后取前 3 个再拼接），GROUP_CONCAT 就力不从心了。这时应转向窗口函数组合。
- MySQL 8.0+ 示例：
GROUP_CONCAT(name ORDER BY score DESC SEPARATOR ';') FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC) rn FROM items) t WHERE rn - PostgreSQL 更简洁：
STRING_AGG(name, ',' ORDER BY score DESC) FILTER (WHERE rn - 关键点：先用窗口函数生成序号或排名，再在外层过滤，最后聚合——顺序控制和数量控制彻底解耦
group_concat_max_len 截断问题：日志里看不出异常，数据却少了一半，尤其当分组内行数波动大时。务必把它当成必检项。 
