我的下载的是mysql-5.7.9绿色版出的问题。最终解决过程供你参考:
1、下载的mysql-5.7.9,出现你的问题。试了各种办法无法解决。有网友说mysql-5.7.9版本有问题。我改下载了5.6.27版本,尝试不成功。但报错变为:无法启动mysql服务,发生错误1067。解决办法:my.ini 添加 tmpdir = D:\mysql-5.6.27-winx64\data。问题解决。
2、后来我对比了mysql-5.7.9与5.6.27,发现mysql-5.7.9-winx64没有data目录,mysql-5.6.27-winx64\data\mysql,存了不少数据文件。原来调试5.7.9的版本时,记得日志报告一直有mysql.user、mysql.plugin不存在的提示。(原以为这些文件会自动生成)。后来把这个mysql-5.6.27-winx64\data下的mysql文件夹整个复制到5.7.9版本中的同目录下。问题解决。
在执行一个sql文件时 mysql -h 127.0.0.1 -uroot study -e"source b.sql" ,报错 MySQL server has gone away 。上网查解决办法,按照网上的解决方法一步步 *** 作,最终找到原因并且解决了,觉得有必要总结下这个问题发生的原因及解决办法,避免后面再继续踩坑。
执行以下命令,查看mysql的运行时长。
uptime数值很大,表明mysql服务运行很久,说明最近MySQL服务器没有重启过。
或者查看MySQL的报错日志,看看有没有重启的信息。
如果日志没有相关信息,也表明mysql服务最近没有重启过,可以继续检查下面几项情况。
如果程序使用的是长连接,则这种情况的可能性会比较大。
即,某个长连接很久没有新的请求发起,达到了server端的timeout,被server强行关闭。
此后再通过这个connection发起查询的时候,就会报错server has gone away。
如下命令设置连接超时为5秒。
再执行 SELECT NOW(),通过这个connection发起查询的时候,就会报错server has gone away。
实际上wait_timeout=28800,不是造成文章开头的原因。
这种情况和情况2相似,只是发起者是DBA或者其他job。发现有长时间的慢查询执行kill xxx导致。
当查询的结果集超过 max_allowed_packet 也会出现这样的报错。
查看执行SQL执行文件大小是否超过 max_allowed_packet ,如果超过则需要调整参数,或者优化语句。
计算发现SQL执行文件最大只能是16M,而文章开头执行的a.sql有24M。
修改参数,max_allowed_packet 调整为28M。
重新再执行`mysql -h 127.0.0.1 -uroot study -e"source b.sql"``成功,说明原因是情况4造成的。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)