mysql出现ERROR问题:(2006, ‘MySQL server has gone away‘)

目次

• 一、问题分析
• 二、缘故原由
• 三、分析缘故原由
• 缘故原由一：MYSQL服务宕机了
• 缘故原由二：MYSQL链接超时
• 缘故原由三：MYSQL请求链接进程被自动KILL
• 缘故原由四：your SQL statement was too large
• 三、处理惩罚
• 总结

一、问题分析

mysql出现

的问题意思就是指client和MySQL server之间的链接断开了。

二、缘故原由

造成如许的缘故原由，最常见的就是收罗或者新旧数据转化：

一样寻常说sql操作的时间过长，或者是传送的数据太大(比方使用insert ... values的语句过长， 这种情况可以通过修改max_allowed_packed的设置参数来避免，也可以在步伐中将数据分批插入(使用mysql limit举行分页，循环分批处理惩罚数据))；

应用步伐（比如PHP）长时间的实行批量的MYSQL语句。实行一个SQL，但SQL语句过大或者语句中含有BLOB或者longblob字段。比如，图片数据的处理惩罚。都容易引起MySQL server has gone away。

• 一种可能是发送的SQL语句太长，以致超过了max_allowed_packet的巨细，只要修改my.cnf，加大max_allowed_packet的值即可。
• 一种可能是由于某些缘故原由导致超时，比如说步伐中获取数据库毗连时采用了Singleton的做法，虽然多次毗连数据库，但其实使用的都是同一个毗连，而且步伐中某两次操作数据库的间隔时间超过了wait_timeout（SHOW STATUS能看到此设置），那么就可能出现问题。最简朴的处理惩罚方式就是把wait_timeout改大，固然你也可以在步伐里时不时随手mysql_ping()一下，如许MySQL就知道它不是一个人在战斗。

三、分析缘故原由

缘故原由一：MYSQL服务宕机了

判断是否属于这个缘故原由的方法很简朴，进入mysql控制台，查看mysql的运行时长

或者查看MySQL的报错日志，看看有没有重启的信息—— 假如uptime数值很大，表明mysql服务运行了好久了。阐明近来服务没有重启过。

假如日志没有相关信息，也表名mysql服务近来没有重启过，可以继续检查下面几项内容。

缘故原由二：MYSQL链接超时

即某个mysql长毗连好久没有新的请求发起，到达了server端的timeout，被server强行关闭。

此后再通过这个connection发起查询的时候，就会报错server has gone away （大部门PHP脚本就是属于此类）

wait_timeout 是28800秒，即mysql链接在无操作28800秒后被自动关闭

缘故原由三：MYSQL请求链接进程被自动KILL

这种情况和缘故原由二相似，只是一个是人为一个是MYSQL自己的动作

缘故原由四：your SQL statement was too large

当查询的效果集超过 max_allowed_packet 也会出现如许的报错。定位方法是打出相关报错的语句。

用select * into outfile 的方式导出到文件，查看文件巨细是否超过 max_allowed_packet ，假如超过则必要调解参数，或者优化语句。

三、处理惩罚

修改参数：

这种情况可以通过修改max_allowed_packed的设置参数来避免，也可以在步伐中将数据分批插入(使用mysql limit举行分页，循环分批处理惩罚数据)

总结

以上为个人经验，希望能给各人一个参考，也希望各人多多支持脚本之家。