项目是java+mysql进行开发的，开发完成后打成war包，部署在tomcat中。 项目是橱柜厂的erp项目，项目部署在了工厂的一台机器上面。 由于数据库默认的max_allowed_packet的大小是4M，刚开始并没有出现任何问题。用了一段时间后开始出现packet for query is too large,第一次出现这个问题并没在意，只是在mysql的my.ini文件里把max_allowed_packet的值改为64M。 之后又出现了好几次packet for query is too large。然后查看my.ini文件max_allowed_packet的值是64M啊，但是用navicat工具输入
select @@max_allowed_packet
查询到的结果却是1024。
于是开始在网上查询max_allowed_packet自动置为1024的文章，主要有下面几种说法：
内存不够，工厂服务器的内存16G，比我开发用的电脑都大（8G）数据库密码过于简单，我们用的密码是root； 由于需要其他工厂的电脑也连服务器的数据库，设置了一个root%用户，就是任何ip都可以访问；所以容易被黑客攻击。 说实话，刚开始并不相信是被黑客攻击了，黑客攻击这小服务器干啥。这个问题并没有从根本上解决，我们决定把数据库的密码改复杂一些，但由于工厂需要改的地方比较多，决定在工厂休息那天进行修改数据库连接密码及其他安全措施。 但怕max_allowed_packet又自动变成1024，决定用mysql的事件进行监控，每隔30分钟查询一次max_allowed_packet，如果为1024，
set global max_allowed_packet = 64M;
第二天放假，由于工厂停电，来电后连项目登陆页面都不能访问，之前虽然报packet for query is too large，但大部分页面还是可以使用的，开始找问题的原因，由于能连接到工厂的数据库，连上后发现项目的数据库已经被删了。 mysql的sys和performance_schema以及项目的数据都没了，还多出来一个warning； 才知道真的被攻击了，勒索我们0.1个比特币。 之前都是修改max_allowed_packet参数为1024，难道mysql的事件被他发现了，这回直接把数据库给删了，这个不得而知。 万幸的是，我们开启了每天晚上8点的数据备份。重新导入数据后，项目可以访问了。 到了下午，又报packet for query is too large的错，以为改下参数或重启mysql服务就可以了。于是想先查询了一下max_allowed_packet的值，但是直接查不到，原因是因为performance_schema数据库不见了，最后只能重新安装mysql，工厂为了数据不出现错误，已经放假了。
然后晚上我们公司的大佬和公司老板一起去了工厂，在另一台机器上部署项目，mysql的密码也复杂了，工厂已关闭了外网，不知道这样还会不会被攻击，接下来看看吧！
