group_concat内部order by必须写在函数括号内，外部order by仅影响结果集行序，不影响拼接顺序；数字字符串需用name+0或length(name),name排序；中文排序需确保连接字符集为utf8mb4；开启only_full_group_by时，order by字段须在group by中或使用聚合函数。
GROUP_CONCAT内部ORDER BY必须写在括号里，不能放外面
很多人写成 SELECT GROUP_CONCAT(name), ... FROM t GROUP BY x ORDER BY name，结果发现拼接顺序还是乱的。这是因为外部ORDER BY只影响最终结果集的行序，不影响GROUP_CONCAT内部的拼接顺序。
正确写法是把排序逻辑直接塞进函数参数里：
SELECT GROUP_CONCAT(name ORDER BY name ASC) AS names FROM t GROUP BY category;
常见错误现象：分组后每组拼出的字符串顺序每次查询都不一样，甚至同一语句反复执行结果也不同——这基本就是没在GROUP_CONCAT里加ORDER BY。
数字字符串排序错位：name+0 或 length(name), name
当拼接字段是数字型但存为VARCHAR（比如'5'、'12'、'100'），直接ORDER BY name会按字典序排成'100','12','5'，而不是数值顺序。
两种可靠解法：
-
ORDER BY name+0：MySQL会隐式转成数字比较，适合纯数字字符串 -
ORDER BY LENGTH(name), name：先比长度再比字典序，兼容含前导零或混合字符的场景
注意：CAST(name AS UNSIGNED)也可用，但在排序上下文中不如name+0简洁；而CONVERT(name, SIGNED)在某些版本可能触发警告。
中文排序失效或乱序：确认连接层字符集是utf8mb4
即使字段定义是utf8mb4，如果客户端连接字符集不是utf8mb4，ORDER BY在GROUP_CONCAT里也可能按字节序排，导致中文顺序错乱（比如“北京”排在“上海”后面，仅因首字UTF-8编码值小）。
检查并修复步骤：
- 运行
SHOW VARIABLES LIKE 'character_set%';，确保character_set_client、character_set_connection、character_set_results全是utf8mb4 - 临时修复：查询前执行
SET NAMES utf8mb4; - 长期方案：在应用连接串中显式指定
charset=utf8mb4（如 PDO 的 DSN）
别试图用 CONVERT(GROUP_CONCAT(...) USING utf8mb4) 补救——拼接过程已经用错字符集完成了，转换只是亡羊补牢。
ORDER BY字段不在GROUP BY里？小心ONLY_FULL_GROUP_BY报错
开启ONLY_FULL_GROUP_BY模式（MySQL 5.7+默认）时，如果GROUP_CONCAT(name ORDER BY create_time)里的create_time没出现在GROUP BY子句或聚合函数中，会直接报错：Expression #1 of ORDER BY clause is not in GROUP BY clause。
解决方式取决于业务需求：
- 若
create_time在分组内唯一（比如每组只有一条记录），可加到GROUP BY列表里 - 若想按某字段最新值排序，改用
ORDER BY MAX(create_time)或ORDER BY MIN(create_time) - 若该字段本身是分组键的一部分（如
GROUP BY user_id, status），而create_time属于该组合，则无需额外处理
最易被忽略的是：这个限制不报错时，ORDER BY可能静默失效——表面能跑，实际排序不可靠。
