mysql 1301_sql错误1301 Result of CONCAT() was larger than max_allowed_packet(1024)-truncated

问题描述：

sql错误1301

问题描述，CONCAT拼接JSON长字符串失败。注，括号内数字可变，为你的当前设置(估计是我这个版本的mysql默认值)

脑残解决方法：一个CONCAT()内不放太多参数

脑残原因：限制的是最终字符串长度，只要目标字符串不变，都会超长。

原因解析：参数——“包裹”大小——设置短了

首先是sql语句查看该参数

show VARIABLES like '%max_allowed_packet%';

我的是1024

解决方法：直接用sql命令修改：

set global max_allowed_packet = 25600;

再

show VARIABLES like '%max_allowed_packet%';

还是不对！

需要

重启mysqld服务

(任何小改动都可能需要重启，要养成习惯，下意识想起来自己还没重启服务)，去linux 命令行完成

#/etc/init.d/mysqld restart

修改成功

使用concat()拼接字符串成功

根据一个从1048576改到2*1024*1024*10的例子，还有4194304的，本例也不显大吧

移动流量也一般，如果要显示这么多数据，本例是显示好友图片说说列表，以及被赞情况，既然要显示那么多人，分次交互和单次交互都刷流量，而且远没有图片流量大。

其次，这个限制和流量没有必然关系，首先是服务器的逻辑，抛出服务器的逻辑，这个也不代表包就那么大，这只是什么最大缓存之类的吧？和服务器端CPU、内存的性能反倒可能有点联系。

但是片面调大是不是有数据库变慢的影响呢？至少要注意，测试服务器搬到正式服务器的话，正式服务器要同步修改mysql这个限制，反正就是很多设置得同步，不然麻烦多，还不容易发现

另外，还有个slave_max_allowed_packet，不知何用

还有

# join_buffer_size = 128M

# sort_buffer_size = 2M

# read_rnd_buffer_size = 2M

等，或许，这个和通信流量有关？不过都注释掉了，未生效

最新：

第一种方法出现了反复，并且再设置后重启mysqld，max_allowed_packet也不是自己用set语句设置的25600，而是4194304，同步了正式服务器的设置，所以两个服务器一定是使用某种配置文件完成的，但是本例确实不是/etc/my.cnf。

最终解决问题的方法：

倾向于用/etc/my.cnf配置文件直接写入

max_allowed_packet = 25600

完成设置

重启/etc/init.d/mysqld

设置成功：

但是25600也不大，会有其他方面的隐患，不差资源的话多设置点吧，多加俩0什么的，参考上边的例子