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
參數的作用是，用來控制其通訊緩衝區的最大長度。