設置mysql數據庫超時（mysql sql執行超時時間）

本文目錄一覽：

• 1、怎樣配置MySQL數據庫超時設置
• 2、MySql執行超時怎麼設置
• 3、如何配置MySQL數據庫超時設置
• 4、mysql怎麼設置超時時間

怎樣配置MySQL數據庫超時設置

mysql命令

查看mysql server超時時間：

msyql show global variables like ‘%timeout%’;

設置mysql server超時時間（以秒為單位）：

msyql set global wait_timeout=10;

msyql set global interactive_timeout=10;

MySql執行超時怎麼設置

MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客戶端中用來設置讀取超時時間的參數。在 MySQL 的官方文檔中，該參數的描述是這樣的：

MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)The timeout in seconds for each attempt to read from the server. There are retries if necessary, so the total effective timeout value is three times the option value. You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes.

也就是說在需要的時候，實際的超時時間會是設定值的 3 倍。但是實際測試後發現實際的超時時間和設置的超時時間一致。

而具體什麼時候發生三倍超時，在文檔中沒有找到。所以對 MySQL 5.7.20 的源碼進行了一些分析。

使用 GDB 調試代碼找了實際與 mysql server 通信的代碼，如下：

請點擊輸入圖片描述

其中 vio_read() 函數中，使用 recv 和 poll 來讀取報文和做讀取超時。net_should_retry() 函數只有在發生 EINTR 時才會返回 true。從這段代碼來看是符合測試結果的，並沒有對讀取進行三次重試。只有在讀取操作被系統中斷打斷時才會重試，但是這個重試並沒有次數限制。

從上面代碼的分析可以看出，代碼的邏輯和文檔的描述不符。於是在一頓搜索後，找到了一個 MySQL 的 BUG(Bug #31163)。該 BUG 報告了在 MySQL 5.0 中，MySQL c api 讀取的實際超時時間是設置的三倍，與現有文檔描述相符。於是對 MySQL 5.0.96 的代碼又進行分析。

同樣使用 GDB 找到了通信部分的代碼。這次找到了重試三次的代碼，如下：

請點擊輸入圖片描述

這個版本的 MySQL api 的讀寫超時是直接使用的 setsockopt 設置的。第一次循環，在 A 點發生了第一次超時（雖然注釋寫的非阻塞，但是客戶端的連接始終是阻塞模式的）。然後在 B 點將該 socket 設置為阻塞模式，C 點這裡重置 retry 次數。由於設置了 alarm 第二次以後的循環會直接進入 D 點的這個分支，並且判斷循環次數。作為客戶端時net-retry_count 始終是 1，所以重試了兩次，共計進行了 3 次 vioread 後從 E 點退出函數。

由上面的分析可知，MySQL 文檔對於該參數的描述已經過時，現在的 MYSQL_OPT_READ_TIMEOUT 並不會出現三倍超時的問題。而 Bug #31163 中的處理結果也是將文檔中該參數的描述更新為實際讀取超時時間是設定時間的三倍。也許是 MySQL 的維護者們在後續版本更新時忘記更新文檔吧。

如何配置MySQL數據庫超時設置

大規模多線程操作事務的時候，有時候打開一個鏈接，會進行等待，這時候如果數據庫的超時時間設置的過短，就可能會出現，數據鏈接自動被釋放，當然設置過大也不好，慢SQL或其他因素引起的鏈接過長，導致整個系統被拖慢，甚至掛掉。SO，適當的設置超時時間。設置方法：

SHOW GLOBAL VARIABLES LIKE ‘%timeout%’

SET GLOBAL wait_timeout=10000

網頁鏈接

mysql怎麼設置超時時間

MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客戶端中用來設置讀取超時時間的參數。在 MySQL 的官方文檔中，該參數的描述是這樣的：

MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)The timeout in seconds for each attempt to read from the server. There are retries if necessary, so the total effective timeout value is three times the option value. You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes.

也就是說在需要的時候，實際的超時時間會是設定值的 3 倍。但是實際測試後發現實際的超時時間和設置的超時時間一致。

而具體什麼時候發生三倍超時，在文檔中沒有找到。所以對 MySQL 5.7.20 的源碼進行了一些分析。

使用 GDB 調試代碼找了實際與 mysql server 通信的代碼，如下：

請點擊輸入圖片描述

其中 vio_read() 函數中，使用 recv 和 poll 來讀取報文和做讀取超時。net_should_retry() 函數只有在發生 EINTR 時才會返回 true。從這段代碼來看是符合測試結果的，並沒有對讀取進行三次重試。只有在讀取操作被系統中斷打斷時才會重試，但是這個重試並沒有次數限制。

從上面代碼的分析可以看出，代碼的邏輯和文檔的描述不符。於是在一頓搜索後，找到了一個 MySQL 的 BUG(Bug #31163)。該 BUG 報告了在 MySQL 5.0 中，MySQL c api 讀取的實際超時時間是設置的三倍，與現有文檔描述相符。於是對 MySQL 5.0.96 的代碼又進行分析。

同樣使用 GDB 找到了通信部分的代碼。這次找到了重試三次的代碼，如下：

請點擊輸入圖片描述

這個版本的 MySQL api 的讀寫超時是直接使用的 setsockopt 設置的。第一次循環，在 A 點發生了第一次超時（雖然注釋寫的非阻塞，但是客戶端的連接始終是阻塞模式的）。然後在 B 點將該 socket 設置為阻塞模式，C 點這裡重置 retry 次數。由於設置了 alarm 第二次以後的循環會直接進入 D 點的這個分支，並且判斷循環次數。作為客戶端時net-retry_count 始終是 1，所以重試了兩次，共計進行了 3 次 vioread 後從 E 點退出函數。

由上面的分析可知，MySQL 文檔對於該參數的描述已經過時，現在的 MYSQL_OPT_READ_TIMEOUT 並不會出現三倍超時的問題。而 Bug #31163 中的處理結果也是將文檔中該參數的描述更新為實際讀取超時時間是設定時間的三倍。也許是 MySQL 的維護者們在後續版本更新時忘記更新文檔吧。