應用程式總會在每天早晨的時候出一次錯，在應用程式日誌中，我發現總有一些“MySQL server has gone away”這樣的錯誤資訊，但是檢查資料庫日誌又並沒有像它描述那樣真的gone away，請問這種錯誤是如何產生的呢？怎麼解決這個問題？
原因有二：
1.空閒等待超時，最常見的原因
- 修改wait_timeout值
- 增加超時自動重連，使用mysql_ping()
2.通訊緩衝區太小
- 修改MySQL的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.pythontab.com');
$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執行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彙報中會有吧。