MySQL 5.5.28 on Ubuntu 12.04
If the result is longer than group_concat_max_len then the result is gracelessly truncated.
Currently I have a script that tries to check the required length ahead of time and sets group_concat_max_len to be large enough.
But the checking adds extra queries. Is there any downside to just setting group_concat_max_len to the maximum value? The upside is fewer queries.
I appreciate this question is a bit old now, but in case someone finds it and is wondering, one downside of setting the maximum (or an otherwise very large) value is that group_concat can return a blob rather than a varchar. Suggestions elsewhere say to set group_concat_max_len to 512 to make it always return a varchar rather than a blob. I tend to just cast it to char where necessary though.
As per MySQL BOL Here
The maximum value for
group_concat_max_lenfor 64-bit is18446744073709551615&
The maximum value for
group_concat_max_lenfor 32-bit is4294967295
The result is truncated to the maximum length that is given by the group_concat_max_len system variable, which has a default value of 1024. The value can be set higher, although the effective maximum length of the return value is constrained by the value of max_allowed_packet. The syntax to change the value of group_concat_max_len at runtime is as follows, where val is an unsigned integer:
SET [GLOBAL | SESSION] group_concat_max_len = val;
Note: The maximum permitted result length in bytes for the GROUP_CONCAT() function. The default is 1024.
As MySQL documented blog Here Using GROUP_CONCAT with a small group_concat_max_len setting? Your result will be silently truncated (make sure to check the warnings though).
As MySQL Blog by @Shlomi Noach Here group_concat_max_len: This parameter limits the maximum text length of a GROUP_CONCAT concatenation result. It defaults to 1024. I think this is a very low value. I have been using GROUP_CONCAT more and more, recently, to solve otherwise difficult problems. And in most cases, 1024 was just too low, resulting in silent (Argh!) truncating of the result, thus returning incorrect results. It is interesting to learn that the maximum value for this parameter is limited by max_packet_size. I would suggest, then, that this parameter should be altogether removed, and have the max_packet_size limitation as the only limitation. Otherwise, I'd like it to have a very large default value, in the order of a few MB.
