背景
平時與開發交流，或在論壇回答問題時，發現這個問題被問及的頻率非常高，例如： 程式中報錯 “MySQL server has gone away” 是什麼意思? 如何避免? 因此，感覺有必要總結一下發生這個問題的原因。
正好看到一篇外文 blog 總結的比較好，就翻譯過來了，分享給大家。
原因一： MySQL 服務宕了
判斷是否屬於這個原因的方法很簡單，執行以下命令，檢視 mysql 的執行時長:
$ mysql -uroot -p -e “show global status like ‘uptime’;”+—————+——-+
| Variable_name | Value |
+—————+——-+
| Uptime | 68928 |
+—————+——-+
1 row in set (0.04 sec)
或者檢視 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 端的 time out，被 server 強行關閉。此後再透過這個 client 發起查詢的時候，就會報錯 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 secondsmysql> 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> 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)