问题描述:
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什么的,参考上边的例子