解決Lost connection to MySQL server during query錯誤方法

昨天使用Navicat for MySQL導入MySQL數據庫的時候，出現了一個嚴重的錯誤，Lost connection to MySQL server during query，字面意思就是在查詢過程當中丟失鏈接到MySQL服務器。

[Msg] Decompressing...
[Msg] Table Created: wp_wiki_copy
[Msg] Importing Data...
[Msg] 2013 - Lost connection to MySQL server during query
[Msg] Table Restored: wp_wiki_copy
[Msg] Finished - Stopped before completion

個人數據量大概了5萬條，備份的數據庫文件大小有240M，這仍是壓縮了的，確實有點大。

初步判斷是MySQL可能掛掉了，在系統服務裏面查看MySQL的進程並無中止。

最開始考慮是數據庫結構不對，可是我是經過Navicat for MySQL的備份和恢復備份導入數據，應該表結構都在備份文件裏面，應該不是數據庫結構的問題。

網絡環境都是本地。也不多是網絡連接和數據庫服務器的問題。

最後在早上找到了解決方法，在my.ini配置文件 mysqld 節點下添加

max_allowed_packet = 500M

也就是配置MySQL容許的最大數據包大小，上面的500M你能夠根據你的項目修改成你本身的值，只要比要導入的備份文件大就能夠了。

================================知識補充================================

 

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本身的動做

mysql> show global status like 'com_kill';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Com_kill      | 21    |
+---------------+-------+
1 row in set緣由四. Your SQL statement was too large.

當查詢的結果集超過 max_allowed_packet 也會出現這樣的報錯。定位方法是打出相關報錯的語句。

用select * into outfile 的方式導出到文件，查看文件大小是否超過 max_allowed_packet ，若是超過則須要調整參數，或者優化語句。

mysql> show global variables like 'max_allowed_packet';
+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+
1 row in set (0.00 sec)

修改參數：

mysql> set global max_allowed_packet=1024*1024*16;
mysql> show global variables like 'max_allowed_packet';
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| max_allowed_packet | 16777216 |
+--------------------+----------+
1 row in set (0.00 sec)

如下是補充：

應用程序（好比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 

一、應用程序（好比PHP）長時間的執行批量的MYSQL語句。最多見的就是採集或者新舊數據轉化。 
解決方案： 
在my.cnf文件中添加或者修改如下兩個變量： 
wait_timeout=2880000 
interactive_timeout = 2880000 
關於兩個變量的具體說明能夠google或者看官方手冊。若是不能修改my.cnf，則能夠在鏈接數據庫的時候設置CLIENT_INTERACTIVE，好比： 
sql = "set interactive_timeout=24*3600"; 
mysql_real_query(...) 


二、執行一個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 
　　一、應用程序（好比PHP）長時間的執行批量的MYSQL語句。最多見的就是採集或者新舊數據轉化。 
　　解決方案： 
　　在my.cnf文件中添加或者修改如下兩個變量： 
wait_timeout=2880000 
interactive_timeout = 2880000　　關於兩個變量的具體說明能夠google或者看官方手冊。若是不能修改my.cnf，則能夠在鏈接數據庫的時候設置CLIENT_INTERACTIVE，好比： 
sql = "set interactive_timeout=24*3600"; 
mysql_real_query(...) 
　　二、執行一個SQL，但SQL語句過大或者語句中含有BLOB或者longblob字段。好比，圖片數據的處理 
　　解決方案： 
　　在my.cnf文件中添加或者修改如下變量： 
max_allowed_packet = 10M(也能夠設置本身須要的大小) 
max_allowed_packet參數的做用是，用來控制其通訊緩衝區的最大長度。
一、應用程序（好比PHP）長時間的執行批量的MYSQL語句。
最多見的就是採集或者新舊數據轉化。

 

解決方案：

在my.ini文件中添加或者修改如下兩個變量：
wait_timeout=2880000
interactive_timeout = 2880000

關於兩個變量的具體說明能夠google或者看官方手冊。
若是不能修改my.cnf，則能夠在鏈接數據庫的時候設置CLIENT_INTERACTIVE，好比：
sql = "set interactive_timeout=24*3600";
mysql_real_query(...)

二、執行一個SQL，但SQL語句過大或者語句中含有BLOB或者longblob字段。
好比，圖片數據的處理
解決方案

在my.cnf文件中添加或者修改如下變量：
max_allowed_packet = 10M (也能夠設置本身須要的大小)

max_allowed_packet 參數的做用是，用來控制其通訊緩衝區的最大長度。

修改方法

1） 方法1
能夠編輯my.cnf來修改（windows下my.ini）,在[mysqld]段或者mysql的server配置段進行修改。

max_allowed_packet = 20M
若是找不到my.cnf能夠經過

mysql --help | grep my.cnf
去尋找my.cnf文件。

2） 方法2
（很妥協，很糾結的辦法）

進入mysql server

在mysql 命令行中運行

set global max_allowed_packet = 2*1024*1024*10
而後關閉掉這此mysql server連接，再進入。

show VARIABLES like '%max_allowed_packet%';
查看下max_allowed_packet是否編輯成功

－－－－－－－－－－－－ 如下是網絡搜索的資料 －－－－－－－－－－－－－－－－－－－

也許其餘人遇到這個問題，不必定是這兒的緣由，那麼，就把我在網上找到比較全面的分析放到下面：有兩篇，第一篇比較直觀，第二篇比較深奧。解決MySQL server has gone away 2009-01-09 16:23:22今天遇到相似的情景，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一、應用程序（好比PHP）長時間的執行批量的MYSQL語句。最多見的就是採集或者新舊數據轉化。解決方案：在my.cnf文件中添加或者修改如下兩個變量：wait_timeout=2880000interactive_timeout = 2880000　　關於兩個變量的具體說明能夠google或者看官方手冊。若是不能修改my.cnf，則能夠在鏈接數據庫的時候設置CLIENT_INTERACTIVE，好比：sql = "set interactive_timeout=24*3600";mysql_real_query(...)二、執行一個SQL，但SQL語句過大或者語句中含有BLOB或者longblob字段。好比，圖片數據的處理解決方案：在my.cnf文件中添加或者修改如下變量：max_allowed_packet = 10M(也能夠設置本身須要的大小)max_allowed_packet參數的做用是，用來控制其通訊緩衝區的最大長度MySQL: 詭異的MySQL server has gone away及其解決在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.aspxdescription: 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 參數的做用是，用來控制其通訊緩衝區的最大長度。