MySQL server has gone away的原因及解决方案

作者: nick 分类: db, mysql 发布时间: 2014-12-10 14:25 ė 6已关闭评论

常见的原因：
1. 服务器超时，比如说在一个脚本里连接上服务器后进行了一些数据库操作后，就开始冷落了数据库，执行起其他一些非数据库操作的耗时操作，数据库等啊等等啊等，结果超时了，只好关闭连接。如果是这个原因，请加大wait_timeout。
2. 因为SQL语句太长所致，比如插入一个BLOB列，或者用一条INSERT语句同时插入很多行，因为SQL太长，数据库可能就无法接收到完整的 SQL，结果数据库就会觉得客户端出错了，从而关闭连接。如果是这个原因，请加大max_allowed_packet。

MySQL在连接超时这块的参数如下
root@(none) 09:24:51>show variables like ‘%out%’; +——————————+———-+ | Variable_name | Value | +——————————+———-+ | connect_timeout | 10 | | delayed_insert_timeout | 300 | | handlersocket_timeout | 300 | | handlersocket_wrlock_timeout | 12 | | innodb_lock_wait_timeout | 100 | | innodb_rollback_on_timeout | OFF | | interactive_timeout | 28800 | | lock_wait_timeout | 31536000 | | log_output | FILE | | net_read_timeout | 30 | | net_write_timeout | 60 | | slave_net_timeout | 3600 | | wait_timeout | 28800 | +——————————+———-+ 把PHP连接MySQL的连接方式从长连接改成了短连接，就再没出现了。
1.MySQL服务器的wait_timeout参数为默认的28800秒，即8小时。该参数的意思是MySQL等待睡眠的连接的持续时间，如果超过8小时不活动，MySQL就会关闭这个连接。这个参数可以动态修改，但这个参数是session级别的，需要应用重新建立连接获取这个变量值才会生效。
2.PHP的默认php.ini里面，default_socket_timeout参数是默认60s.default_socket_timeout参数的意思是socket超时为60s。官方解释
3.在MySQL的官方文档里面，有专门的章节介绍MySQL Server has gone away。但并没有提及到客户端本身也会有超时机制，以前曾经试过把wait_timeout设置为1年，但App还是继续出现MySQL server has gone away的错误。
4.在PHP程序里面，如果php.ini修改起来不方便，可以以下代码来尝试解决。
ini_set(‘mysql.connect_timeout’, 300); ini_set(‘default_socket_timeout’, 300); 在ini_set后，可以用ini_get来验证参数设置适合符合预期。
参考资料
1. MySQL server has gone away – in exactly 60 seconds
2. MySQL server has gone away

=================

出现这种错误是因为，mysql server关闭了该连接，如果客户端程序在默认的8小时内进行任何数据库操作的话。解决方法有：

1、修改mysql server的my.cnf,通过修改wait_timeout,interactive_timeout，来设置延长超时时间，但是个人不建议这么做，这种操作会导致存在很多的数据库连接存在，影响数据库的性能；

设置方法为：

[mysqld]

wait_timeout=5
interactive_timeout = 5

需要两个变量同时进行设置；

2、设置数据库选项，当连接断开时进行重新连接。

char nvalue = 1;

if(mysql_options(&mysql, MYSQL_OPT_RECONNECT, (char *)&nvalue))
printf(“mysql_options/r/n”);

3、执行数据库操作前，ping一下数据库，如果数据库无法连接，则断开连接，然后再重启连接。

if(mysql_ping(sqlsock) != 0){ //reconnect failed…Then try connect
CloseDB();

if((sqlsock = mysql_real_connect(&mysql,DBHOST,DBUSER,DBPASSWORD,DBNAME,0,NULL,CLIENT_INTERACTIVE)) == NULL)
{
fprintf(stderr,”Can’t connect to mysql sever! ErrorCode:%s/r/n”,mysql_error(&mysql));

return -1;
}
printf(“ConnectDB/r/n”);
}

为保险起见，我采用重启连接之间进行关闭连接；

对于这种方法，个人建议采用一个线程每隔一定的时间来ping一下，如果ping不通，则重新进行连接操作。

4、跟第一种方法类似，也是设置超时的时间，只是这个超时时间只是对本连接有效；

mysql_options(&mysql,MYSQL_INIT_COMMAND,”set interactive_timeout = 15″);
mysql_options(&mysql,MYSQL_INIT_COMMAND,”set wait_timeout = 15″);

备注：当客户端与服务器之间的连接断开的时候（比如拔掉网线），待网络恢复正常后，连接仍然存在，这是tcp的重传机制在起作用，tcp的重传时间，本机测试超过了10分钟的短线，恢复后仍然正常。

1）没有找到设置tcp重传时间的参数。有知道可以跟帖；

2）如何人为断开数据库连接的情形，本人也没有找到好的方法，稍后可能会测试一下如果长时间断网，如何去恢复数据库连接（打算ping数据库的方法来尝试一下）。

========================

MySQL server has gone away报错原因分析

在平时和开发的交流以及在论坛回答问题的或称中会发现这个问题被问及的频率非常高。

程序中报错： MySQL server has gone away 是什么意思？如何避免？

因此，感觉有必要总结一下发生这个问题的原因。今天正好看到一篇外文blog总结的比较好，就翻译过来了

原文：http://ronaldbradford.com/blog/s … ne-away-2013-01-02/

原因1. MySQL 服务宕了

判断是否属于这个原因的方法很简单，执行以下命令，查看mysql的运行时长

或者查看MySQL的报错日志，看看有没有重启的信息

$ tail /var/log/mysql/error.log
130101 22:22:30 InnoDB: Initializing buffer pool, size = 256.0M
130101 22:22:30 InnoDB: Completed initialization of buffer pool
130101 22:22:30 InnoDB: highest supported file format is Barracuda.
130101 22:22:30 InnoDB: 1.1.8 started; log sequence number 63444325509
130101 22:22:30 [Note] Server hostname (bind-address): ‘127.0.0.1’; port: 3306
130101 22:22:30 [Note] – ‘127.0.0.1’ resolves to ‘127.0.0.1’;
130101 22:22:30 [Note] Server socket created on IP: ‘127.0.0.1’.
130101 22:22:30 [Note] Event Scheduler: Loaded 0 events
130101 22:22:30 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‘5.5.28-cll’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL)

如果uptime数值很大，表明mysql服务运行了很久了。说明最近服务没有重启过。

如果日志没有相关信息，也表名mysql服务最近没有重启过，可以继续检查下面几项内容。
2. 连接超时

如果程序使用的是长连接，则这种情况的可能性会比较大。

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

此后再通过这个connection发起查询的时候，就会报错server has gone away

$ mysql -uroot -p -e “show global variables like ‘%timeout’;”
+—————————-+———-+
| Variable_name             | Value |
+—————————-+———-+
| connect_timeout          | 30    |
| delayed_insert_timeout    | 300    |
| innodb_lock_wait_timeout | 50    |
| innodb_rollback_on_timeout | OFF    |
| interactive_timeout       | 28800 |
| lock_wait_timeout       | 31536000 |
| net_read_timeout          | 30    |
| net_write_timeout       | 60    |
| slave_net_timeout       | 3600    |
| wait_timeout             | 28800 |
+—————————-+———-+

mysql> SET SESSION wait_timeout=5;

## Wait 10 seconds

mysql> SELECT NOW();
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect…
Connection id: 132361
Current database: *** NONE ***

+———————+
| NOW() |
+———————+
| 2013-01-02 11:31:15 |
+———————+
1 row in set (0.00 sec)

3. 进程在server端被主动kill

这种情况和情况2相似，只是发起者是DBA或者其他job。发现有长时间的慢查询执行kill xxx导致。

$ mysql -uroot -p -e “show global status like ‘com_kill'”
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Com_kill | 0 |
+—————+——-+

4. Your SQL statement was too large.

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

用select * into outfile 的方式导出到文件，查看文件大小是否超过 max_allowed_packet ，如果超过则需要调整参数，或者优化语句。

修改参数：

=============

mysql出现ERROR : (2006, ‘MySQL server has gone away’) 的问题意思就是指client和MySQL server之间的链接断开了。

造成这样的原因一般是sql操作的时间过长，或者是传送的数据太大(例如使用insert … values的语句过长，这种情况可以通过修改max_allowed_packed的配置参数来避免，也可以在程序中将数据分批插入)。

产生这个问题的原因有很多，总结下网上的分析：

原因一. MySQL 服务宕了

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

mysql> show global status like ‘uptime’;
+—————+———+
| Variable_name | Value |
+—————+———+
| Uptime | 3414707 |
+—————+———+

1 row in set或者查看MySQL的报错日志，看看有没有重启的信息

如果uptime数值很大，表明mysql服务运行了很久了。说明最近服务没有重启过。
如果日志没有相关信息，也表名mysql服务最近没有重启过，可以继续检查下面几项内容。

原因二. mysql连接超时

即某个mysql长连接很久没有新的请求发起，达到了server端的timeout，被server强行关闭。
此后再通过这个connection发起查询的时候，就会报错server has gone away
（大部分PHP脚本就是属于此类）

mysql> show global variables like ‘%timeout’;
+—————————-+———-+
| Variable_name             | Value |
+—————————-+———-+
| connect_timeout          | 10    |
| delayed_insert_timeout    | 300    |
| innodb_lock_wait_timeout | 50    |
| innodb_rollback_on_timeout | OFF    |
| interactive_timeout       | 28800 |
| lock_wait_timeout       | 31536000 |
| net_read_timeout          | 30    |
| net_write_timeout       | 60    |
| slave_net_timeout       | 3600    |
| wait_timeout             | 28800 |
+—————————-+———-+
10 rows in set

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

原因三. mysql请求链接进程被主动kill

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

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

用select * into outfile 的方式导出到文件，查看文件大小是否超过 max_allowed_packet ，如果超过则需要调整参数，或者优化语句。

修改参数：

以下是补充：

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

今天遇到类似的情景，MySQL只是冷冷的说：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 server has gone away

1、应用程序（比如PHP）长时间的执行批量的MYSQL语句。最常见的就是采集或者新旧数据转化。
解决方案：
在my.cnf文件中添加或者修改以下两个变量：
wait_timeout=2880000
interactive_timeout = 2880000
关于两个变量的具体说明可以google或者看官方手册。如果不能修改my.cnf，则可以在连接数据库的时候设置CLIENT_INTERACTIVE，比如：
sql = “set interactive_timeout=24*3600”;
mysql_real_query(…)

2、执行一个SQL，但SQL语句过大或者语句中含有BLOB或者longblob字段。比如，图片数据的处理
解决方案：
在my.cnf文件中添加或者修改以下变量：
max_allowed_packet = 10M(也可以设置自己需要的大小)
max_allowed_packet 参数的作用是，用来控制其通信缓冲区的最大长度。

最近做网站有一个站要用到WEB网页采集器功能，当一个PHP脚本在请求URL的时候，可能这个被请求的网页非常慢慢，超过了mysql的 wait-timeout时间，然后当网页内容被抓回来后，准备插入到MySQL的时候，发现MySQL的连接超时关闭了，于是就出现了“MySQL server has gone away”这样的错误提示，解决这个问题，我的经验有以下两点，或许对大家有用处：
第一种方法：
当然是增加你的 wait-timeout值，这个参数是在my.cnf(在Windows下台下面是my.ini）中设置，我的数据库负荷稍微大一点，所以，我设置的值为10，（这个值的单位是秒，意思是当一个数据库连接在10秒钟内没有任何操作的话，就会强行关闭，我使用的不是永久链接（mysql_pconnect),用的是mysql_connect,关于这个wait-timeout的效果你可以在MySQL的进程列表中看到（show processlist) ），你可以把这个wait-timeout设置成更大，比如300秒，呵呵，一般来讲300秒足够用了，其实你也可以不用设置，MySQL默认是8个小时。情况由你的服务器和站点来定。
第二种方法：
这也是我个人认为最好的方法，即检查 MySQL的链接状态，使其重新链接。
可能大家都知道有mysql_ping这么一个函数，在很多资料中都说这个mysql_ping的 API会检查数据库是否链接，如果是断开的话会尝试重新连接，但在我的测试过程中发现事实并不是这样子的，是有条件的，必须要通过 mysql_options这个C API传递相关参数，让MYSQL有断开自动链接的选项（MySQL默认为不自动连接），但我测试中发现PHP的MySQL的API中并不带这个函数，你重新编辑MySQL吧，呵呵。但mysql_ping这个函数还是终于能用得上的，只是要在其中有一个小小的操作技巧：
这是我的的数据库操作类中间的一个函数
复制代码代码如下:

function ping(){
if(!mysql_ping($this->link)){
mysql_close($this->link); //注意：一定要先执行数据库关闭，这是关键
$this->connect();
}
}

我需要调用这个函数的代码可能是这样子的
复制代码代码如下:

$str = file_get_contents(‘http://www.jb51.net’);
$db->ping();//经过前面的网页抓取后，或者会导致数据库连接关闭,检查并重新连接
$db->query(‘select * from table’);

ping()这个函数先检测数据连接是否正常，如果被关闭，整个把当前脚本的MYSQL实例关闭，再重新连接。
经过这样处理后，可以非常有效的解决MySQL server has gone away这样的问题，而且不会对系统造成额外的开销。
__________________________________________________________________________________________________
今天遇到类似的情景，MySQL只是冷冷的说：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 server has gone away
1、应用程序（比如PHP）长时间的执行批量的MYSQL语句。最常见的就是采集或者新旧数据转化。
解决方案：
在my.cnf文件中添加或者修改以下两个变量：
wait_timeout=2880000
interactive_timeout = 2880000　　关于两个变量的具体说明可以google或者看官方手册。如果不能修改my.cnf，则可以在连接数据库的时候设置CLIENT_INTERACTIVE，比如：
sql = “set interactive_timeout=24*3600”;
mysql_real_query(…)
2、执行一个SQL，但SQL语句过大或者语句中含有BLOB或者longblob字段。比如，图片数据的处理
解决方案：
在my.cnf文件中添加或者修改以下变量：
max_allowed_packet = 10M(也可以设置自己需要的大小)
max_allowed_packet参数的作用是，用来控制其通信缓冲区的最大长度。
1、应用程序（比如PHP）长时间的执行批量的MYSQL语句。
最常见的就是采集或者新旧数据转化。

解决方案：

在my.ini文件中添加或者修改以下两个变量：
wait_timeout=2880000
interactive_timeout = 2880000

关于两个变量的具体说明可以google或者看官方手册。
如果不能修改my.cnf，则可以在连接数据库的时候设置CLIENT_INTERACTIVE，比如：
sql = “set interactive_timeout=24*3600”;
mysql_real_query(…)

2、执行一个SQL，但SQL语句过大或者语句中含有BLOB或者longblob字段。
比如，图片数据的处理
解决方案

在my.cnf文件中添加或者修改以下变量：
max_allowed_packet = 10M (也可以设置自己需要的大小)

max_allowed_packet 参数的作用是，用来控制其通信缓冲区的最大长度。

－－－－－－－－－－－－以下是网络搜索的资料－－－－－－－－－－－－－－－－－－－

也许其他人遇到这个问题，不一定是这儿的原因，那么，就把我在网上找到比较全面的分析放到下面：
有两篇，第一篇比较直观，第二篇比较深奥。
解决MySQL server has gone away 2009-01-09 16:23:22
来自：http://www.webjx.com/database/mysql-8817.html
今天遇到类似的情景，MySQL只是冷冷的说：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 server has gone away

1、应用程序（比如PHP）长时间的执行批量的MYSQL语句。最常见的就是采集或者新旧数据转化。

解决方案：

在my.cnf文件中添加或者修改以下两个变量：

wait_timeout=2880000
interactive_timeout = 2880000
关于两个变量的具体说明可以google或者看官方手册。如果不能修改my.cnf，则可以在连接数据库的时候设置CLIENT_INTERACTIVE，比如：

sql = “set interactive_timeout=24*3600”;
mysql_real_query(…)

2、执行一个SQL，但SQL语句过大或者语句中含有BLOB或者longblob字段。比如，图片数据的处理

解决方案：

在my.cnf文件中添加或者修改以下变量：

max_allowed_packet = 10M
(也可以设置自己需要的大小)

max_allowed_packet
参数的作用是，用来控制其通信缓冲区的最大长度

MySQL: 诡异的MySQL server has gone away及其解决
来自：http://fz9493.blog.sohu.com/38472203.html

jimmy | 15 三月, 2007 20:32

在Mysql执行show status，通常更关注缓存效果、进程数等，往往忽略了两个值：

Variable_name Value
Aborted_clients 3792
Aborted_connects 376

通常只占query的0.0x%，所以并不为人所**。而且在传统Web应用上，query错误对用户而言影响并不大，只是重新刷新一下页面就OK了。最近的基础改造中，把很多应用作为service运行，无法提示用户重新刷新，这种情况下，可能就会影响到服务的品质。

通过程序脚本的日志跟踪，主要报错信息为“MySQL server has gone away”。官方的解释是：

The most common reason for the MySQL server has gone away error is that the server timed out and closed the connection.

Some other common reasons for the MySQL server has gone away error are:

You (or the db administrator) has killed the running thread with a KILL statement or a mysqladmin kill command.

You tried to run a query after closing the connection to the server. This indicates a logic error in the application that should be corrected.

A client application running on a different host does not have the necessary privileges to connect to the MySQL server from that host.

You got a timeout from the TCP/IP connection on the client side. This may happen if you have been using the commands: mysql_options(…, MYSQL_OPT_READ_TIMEOUT,…) or mysql_options(…, MYSQL_OPT_WRITE_TIMEOUT,…). In this case increasing the timeout may help solve the problem.

You have encountered a timeout on the server side and the automatic reconnection in the client is disabled (the reconnect flag in the MYSQL structure is equal to 0).

You are using a Windows client and the server had dropped the connection (probably because wait_timeout expired) before the command was issued.

The problem on Windows is that in some cases MySQL doesn’t get an error from the OS when writing to the TCP/IP connection to the server, but instead gets the error when trying to read the answer from the connection.

In this case, even if the reconnect flag in the MYSQL structure is equal to 1, MySQL does not automatically reconnect and re-issue the query as it doesn’t know if the server did get the original query or not.

The solution to this is to either do a mysql_ping on the connection if there has been a long time since the last query (this is what MyODBC does) or set wait_timeout on the mysqld server so high that it in practice never times out.

You can also get these errors if you send a query to the server that is incorrect or too large. If mysqld receives a packet that is too large or out of order, it assumes that something has gone wrong with the client and closes the connection. If you need big queries (for example, if you are working with big BLOB columns), you can increase the query limit by setting the server’s max_allowed_packet variable, which has a default value of 1MB. You may also need to increase the maximum packet size on the client end. More information on setting the packet size is given in Section A.1.2.9, “Packet too large”.

An INSERT or REPLACE statement that inserts a great many rows can also cause these sorts of errors. Either one of these statements sends a single request to the server irrespective of the number of rows to be inserted; thus, you can often avoid the error by reducing the number of rows sent per INSERT or REPLACE.

You also get a lost connection if you are sending a packet 16MB or larger if your client is older than 4.0.8 and your server is 4.0.8 and above, or the other way around.

It is also possible to see this error if hostname lookups fail (for example, if the DNS server on which your server or network relies goes down). This is because MySQL is dependent on the host system for name resolution, but has no way of knowing whether it is working — from MySQL’s point of view the problem is indistinguishable from any other network timeout.

You may also see the MySQL server has gone away error if MySQL is started with the –skip-networking option.

Another networking issue that can cause this error occurs if the MySQL port (default 3306) is blocked by your firewall, thus preventing any connections at all to the MySQL server.

You can also encounter this error with applications that fork child processes, all of which try to use the same connection to the MySQL server. This can be avoided by using a separate connection for each child process.

You have encountered a bug where the server died while executing the query.

据此分析，可能原因有3：

1，Mysql服务端与客户端版本不匹配。

2，Mysql服务端配置有缺陷或者优化不足

3，需要改进程序脚本

通过更换多个服务端与客户端版本，发现只能部分减少报错，并不能完全解决。排除1。

对服务端进行了彻底的优化，也未能达到理想效果。在timeout的取值设置上，从经验值的10，到PHP默认的60，进行了多次尝试。而Mysql官方默认值(8小时)明显是不可能的。从而对2也进行了排除。(更多优化的经验分享，将在以后整理提供)

针对3对程序代码进行分析，发现程序中大量应用了类似如下的代码(为便于理解，用原始api描述)：

$conn=mysql_connect( … … );

… … … …

if(!$conn){ //reconnect

$conn=mysql_connect( … … );

}

mysql_query($sql, $conn);

这段代码的含义，与Mysql官方建议的方法思路相符[ If you have a script, you just have to issue the query again for the client to do an automatic reconnection. ]。在实际分析中发现，if(!$conn)并不是可靠的，程序通过了if(!$conn)的检验后，仍然会返回上述错误。

对程序进行了改写：

if(!conn){ // connect …}

elseif(!mysql_ping($conn)){ // reconnect … }

mysql_query($sql, $conn);

经实际观测，MySQL server has gone away的报错基本解决。

BTW：附带一个关于 reconnect 的疑问，

在php4x+client3x+mysql4x的旧环境下，reconnet的代码：

$conn=mysql_connect(…) 可以正常工作。

但是，在php5x+client4x+mysql4x的新环境下，$conn=mysql_connect(…)返回的$conn有部分情况下不可用。需要书写为：

mysql_close($conn);

$conn=mysql_connect(…);

返回的$conn才可以正常使用。原因未明。未做深入研究，也未见相关讨论。或许mysql官方的BUG汇报中会有吧。

～～呵呵～～

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/brightsnow/archive/2009/03/17/3997705.aspx

description:
remember that your MySQL “max_allowed_packet” configuration setting (default 1MB)
mysql 默认最大能够处理的是1MB
如果你在sql使用了大的text或者BLOB数据，就会出现这个问题。 php手册上的注释

When trying to INSERT or UPDATE and trying to put a large amount of text or data (blob) into a mysql table you might run into problems.
In mysql.err you might see:
Packet too large (73904)
To fix you just have to start up mysql with the option -O max_allowed_packet=maxsize
You would just replace maxsize with the max size you want to insert, the default is 65536

mysql手册上说

Both the client and the server have their own max_allowed_packet variable, so if you want to handle big packets, you must increase this variable both in the client and in the server.

If you are using the mysql client program, its default max_allowed_packet variable is 16MB. To set a larger value, start mysql like this:

shell> mysql –max_allowed_packet=32M That sets the packet size to 32MB.

The server’s default max_allowed_packet value is 1MB. You can increase this if the server needs to handle big queries (for example, if you are working with big BLOB columns). For example, to set the variable to 16MB, start the server like this:

shell> mysqld –max_allowed_packet=16M You can also use an option file to set max_allowed_packet. For example, to set the size for the server to 16MB, add the following lines in an option file:

[mysqld]max_allowed_packet=16M

使用mysql做数据库还原的时候，由于有些数据很大，会出现这样的错误：The MySQL Server returned this Error:MySQL Error Nr.2006-MySQL server has gone away。我的一个150mb的备份还原的时候就出现了这错误。解决的方法就是找到mysql安装目录，找到my.ini文件，在文件的最后添加：max_allowed_packet = 10M(也可以设置自己需要的大小)。 max_allowed_packet 参数的作用是，用来控制其通信缓冲区的最大长度。

==================

本文出自传播、沟通、分享，转载时请注明出处及相应链接。

本文永久链接: https://www.nickdd.cn/?p=2085

0mysql

« JS快速获取图片宽高的方法

介绍JavaScript国际化API »

MySQL server has gone away的原因及解决方案

MySQL server has gone away报错原因分析

分类目录

db 下的最新文章

随机文章

标签云