GROUP_CONCAT只返回一行是因为它为聚合函数，未用GROUP BY时将全表视为一个组；需按业务主键如u.id分组，且SELECT字段须与GROUP BY一致，否则严格模式报错。
GROUP_CONCAT 为什么只返回一行？
因为 GROUP_CONCAT 是聚合函数，必须配合 GROUP BY 使用；没写 GROUP BY 时，MySQL 把整张结果集当做一个组，自然只拼出一条记录。
常见错误现象：SELECT user_id, GROUP_CONCAT(role_name) FROM users u JOIN user_roles ur ON u.id = ur.user_id JOIN roles r ON ur.role_id = r.id; —— 这条语句能跑通，但 user_id 值是随机的（取决于 SQL 模式），GROUP_CONCAT 结果却把所有角色全塞进去了，完全不对齐。
- 正确做法：明确按业务主键
GROUP BY，比如查用户带角色列表，就GROUP BY u.id或GROUP BY u.user_id - 注意字段一致性：
SELECT u.id, u.name, GROUP_CONCAT(r.name)必须和GROUP BY u.id, u.name完全匹配，否则在严格模式下会报错Expression #2 of SELECT list is not in GROUP BY clause - 如果只是想“展开”多对多关系（不聚合），就别用
GROUP_CONCAT，直接多表JOIN查原始行
中间表 JOIN 顺序和性能怎么选？
中间表（如 user_roles）永远是连接枢纽，但 JOIN 顺序直接影响索引是否生效、临时表大小和执行计划。
使用场景：查「有指定角色的用户」或「每个用户的全部角色」，都绕不开中间表。但先连用户还是先连角色，差别很大。
- 优先以「主查询目标表」为驱动表：比如要查用户信息 + 其角色，就
FROM users u JOIN user_roles ur ON u.id = ur.user_id JOIN roles r ON ur.role_id = r.id；反过来先roles再连会扫描大量无关角色 - 确保中间表上有联合索引：
user_roles(user_id, role_id)和user_roles(role_id, user_id)效果不同，前者支撑「查某用户的所有角色」，后者支撑「查某角色的所有用户」 - 加
WHERE条件时别写在最后：像WHERE r.name = 'admin'放在末尾，可能导致 MySQL 先拼完全部关联再过滤；应尽量前推，比如改成JOIN roles r ON ur.role_id = r.id AND r.name = 'admin'
GROUP_CONCAT 超长被截断怎么办？
GROUP_CONCAT 默认长度上限是 1024 字符，超了就无声截断——这是最隐蔽的坑，数据看起来“完整”，其实后面全丢了。
错误现象：明明一个用户有 15 个角色，GROUP_CONCAT 却只返回前 8 个，且无任何警告。
- 临时改法：执行
SET SESSION group_concat_max_len = 10000;（单位是字节，中文算 3 字节） - 永久改法：在 MySQL 配置文件里加
group_concat_max_len = 10000，然后重启服务 - 更稳妥的做法：不在 SQL 层拼太长字符串，而是用应用层做聚合；或者用
GROUP_CONCAT(DISTINCT ...)去重 +ORDER BY控制顺序，减少无效长度
想查「同时拥有 A 和 B 角色的用户」怎么写？
这不是 GROUP_CONCAT 的活，强行用它（比如 HAVING GROUP_CONCAT(r.name) LIKE '%A%B%'）既慢又不准——顺序不确定、可能误匹配子串。
本质是集合交集问题，得靠多次关联或子查询。
- 推荐写法：用两次中间表自连接，
SELECT u.* FROM users u JOIN user_roles ur1 ON u.id = ur1.user_id JOIN roles r1 ON ur1.role_id = r1.id AND r1.name = 'A' JOIN user_roles ur2 ON u.id = ur2.user_id JOIN roles r2 ON ur2.role_id = r2.id AND r2.name = 'B'; - 避免用
IN子查询套两层，容易全表扫描；也别用EXISTS嵌套太多层，可读性差 - 如果角色数动态变化（比如「拥有其中任意 3 个」），就得用
COUNT(DISTINCT r.name)配合GROUP BY u.id HAVING COUNT(...) >= 3，这时才真正需要GROUP_CONCAT辅助调试
多对多的“同时满足”永远比“包含任意一个”难处理，中间表的结构设计和索引覆盖程度，比函数技巧重要得多。
