MySQL JOIN查询返回冗余大数据集传输耗时的优化方案咨询

方案可行性评估 #

你当前用GROUP BY+GROUP_CONCAT的思路是合理的，属于典型的服务端侧合并关联数据、减少传输冗余的优化手段，完全匹配你查询快但传输慢的场景，不过存在几个适用边界需要注意：

• GROUP_CONCAT默认长度限制是1024字节，你调整group_concat_max_len的操作是必要的，单会话调整不会影响全局服务，风险很低。合理取值可以按照单用户关联的最大记录长度估算：比如单条purchase拼接后平均是20字节，单用户最多1000条记录，设置为20*1000=20000就足够，你当前设置的1000000（约1MB）对绝大多数业务场景都够用，只要不会出现单个用户关联数万条purchase的极端情况，就不会有截断风险。
• 建议使用自定义分隔符，比如GROUP_CONCAT(CONCAT(purchase_id, ':', purchase_amount) SEPARATOR '|')，避免业务字段里出现默认逗号导致后续解析出错。
• 适用边界：如果关联的子表字段很多、单个用户关联的记录量极大，拼接后的字符串可能反而比原始冗余数据体积更大，这种场景不推荐用该方案。
• 注意你示例SQL里的JOIN条件users.id和表结构的user_id字段不一致，实际使用需要修正。

其他可行优化方案 #

1. 分两次查询 #

先查Users表的所有用户数据，再查所有符合条件的Purchases表数据，在应用层按user_id做关联匹配。这种方案的优势是完全没有拼接/截断风险，两次简单查询的执行效率比带GROUP BY的SQL更高，尤其是数据量很大的时候性能更稳定。

2. 使用JSON聚合（MySQL 5.7+支持） #

相比纯字符串拼接，JSON格式的解析成本更低，也不需要自己处理分隔符冲突问题，示例SQL如下：

SELECT user_id, user_name, 
JSON_ARRAYAGG(JSON_OBJECT('purchase_id', purchase_id, 'purchase_amount', purchase_amount)) as purchase_list
FROM Users 
LEFT JOIN purchases ON users.user_id = purchases.user_id 
GROUP BY user_id, user_name

返回的purchase_list是标准JSON数组，应用层可以直接反序列化，不需要自己拆分字符串，也能达到减少冗余的效果，同样需要注意json_agg_max_len相关参数的调整。

3. 开启MySQL压缩传输 #

如果不想改查询逻辑，可以在客户端连接MySQL的时候开启压缩协议，直接降低传输阶段的体积，以JDBC为例，连接URL添加useCompression=true参数即可，其他语言的MySQL驱动都有对应的压缩开关，不需要改业务代码就能实现传输提速，适合快速上线的场景。

内容的提问来源于stack exchange，提问作者AlexanderNajafi