mysql 'max_allowed_packet' 自动重置为1M问题

现象描述

        在做java web服务器端开发的时候遇到多条件查询的情况，因为条件较多导致从应用服务器端一次向数据库服务器端传太大的数据量，数据库服务器端和应用服务器端连接出现问题，应用服务器端反馈一个‘max_allowed_packet’超出最大长度1024KB问题。经过多方资料查询确定只要将mysql的配置文件my.cnf里面mysqld节点下面的max_allowed_packet属性值变大即可（默认是1M，我把它改为了16M）,问题就解决了。但是没过几天访问应用的时候又出现了相同的问题，就是说max_allowed_packet值又变成了1M, 然后就重启数据库服务以命令  mysql --max-allowed-packet=32M -u root -p 打开数据库服务终端max_allowed_packet的值就恢复为16M了，不过好景不长过了两天max_allowed_packet的值又从16M变为1M了，以后我又尝试重启服务器然后服务正常恢复（值变为16M）, 奇怪的是不知道为啥max_allowed_packet的值没一两天就会变成1M,搞得我很困惑，服务器是我一个人管理的应该不会有其他人来弄。。。。。 

问题分析

一开始我以为是数据库服务会定时重启导致的，重启后如果不设置max_allowed_packet的值就默认为1M,有这样想法的原因是每次max_allowed_packet的值从16M变为1M后我都重启数据库服务然后通过 mysql --max-allowed-packet=32M -u root -p来设置max_allowed_packet的值，如果数据库服务自行重新启动后不设置max_allowed_packet的值，那么它的值就是默认1M。这一点后来证明错的很远首先数据库是没有自动重启策略这种功能的，另外每次重启都会读取配置文件my.cnf里面的属性值来初始化数据库服务变量，也就是说我把my.cnf里面max_allowed_packet的值改成了16M数据库服务重启后max_allowed_packet默认就是16M,后来又发现mysql --max-allowed-packet=32M -u root -p 压根儿没有用，不会改变mysql --max-allowed-packet=32M -u root -p的值，如下：

（没用mysql --max-allowed-packet=32M -u root -p设置前，max_allowed_packet的值是1M,设置完成后仍然是1M,就没有变。）

在网上看到一种说法是  服务器内存不足mysql重置导致的问题的出现，这种说法和我的猜想很想，但是现在想来也是漏洞百出，就算是重置的话也会以my.cnf配置文件的初始化值来重置呀，my.cnf里面max_allowed_packet的值为16M重置过后也应该是16M才是怎么会变成1M呢，所以此种猜想不成立。

在网上看到的第二种思路是服务器遭到和黑客攻击，黑客把数据库的max_allowed_packet的值给修改了，这种说法通过我个人的实践证明是正解。

问题解决

最直接的方式是修改终端root登录密码，这样子黑客就进不来了，更不会修改数据库服务的参数值了。

参考资料

http://www.oschina.net/question/942822_240062

数据库服务器安全防护思路

服务器要禁止root ssh登录，最好使用普通用户登录;

开启数据库日志功能，便于在遇到问题的时候找出问题。