MySQL數(shù)據(jù)庫連接超時(shí)怎么辦？

1、首先檢查是否已安裝MySQL服務(wù)，如果沒有安裝，則需要安裝MySQL服務(wù)。

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供易縣網(wǎng)站建設(shè)、易縣做網(wǎng)站、易縣網(wǎng)站設(shè)計(jì)、易縣網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、易縣企業(yè)網(wǎng)站模板建站服務(wù)，10多年易縣做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

2、然后檢查MySQL服務(wù)是否已經(jīng)在系統(tǒng)服務(wù)列表中，如果不在則需要手動(dòng)添加MySQL服務(wù)。

3、檢查MySQL的配置文件my.ini是否正確，如果不正確則需要修改配置文件。

4、檢查Windows服務(wù)管理器中MySQL服務(wù)的狀態(tài)是否處于“運(yùn)行”狀態(tài)，如果不是，則需要手動(dòng)啟動(dòng)MySQL服務(wù)。

拓展：

如果以上步驟都無法解決問題，可以嘗試更新MySQL安裝包，或者重新安裝MySQL服務(wù)。如果仍然無法解決，則可以嘗試檢查MySQL的數(shù)據(jù)庫文件是否損壞，如果損壞則需要進(jìn)行修復(fù)。

MySQL連接超時(shí)自動(dòng)斷開連接應(yīng)該怎樣處理

用Fsocket獲取數(shù)據(jù)時(shí)能夠控制超時(shí)的。

如果用

File_get_contents($url);

可以臨時(shí)設(shè)定環(huán)境變量：

設(shè)定默認(rèn)socket超時(shí)時(shí)間

ini_set("default_socket_timeout", 3);養(yǎng)成好習(xí)慣，使用fsocket獲取數(shù)據(jù)。

如果使用Curl，也可以在Curl中控制超時(shí)時(shí)間：

curl_setopt($ch, CURLOPT_TIMEOUT, 15);

PHP中mysql函數(shù)是不提供類似mysql超時(shí)選項(xiàng)的，但是php.ini的mysql.connect_timeout可設(shè)置

; Maximum time (in seconds) for connect timeout. -1 means nolimit

mysql.connect_timeout = 60

也可以在php腳本中調(diào)用設(shè)置ini_set();

mysql連接超時(shí)怎么處理

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

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.

也就是說在需要的時(shí)候，實(shí)際的超時(shí)時(shí)間會是設(shè)定值的 3 倍。但是實(shí)際測試后發(fā)現(xiàn)實(shí)際的超時(shí)時(shí)間和設(shè)置的超時(shí)時(shí)間一致。

而具體什么時(shí)候發(fā)生三倍超時(shí)，在文檔中沒有找到。所以對 MySQL 5.7.20 的源碼進(jìn)行了一些分析。

使用 GDB 調(diào)試代碼找了實(shí)際與 mysql server 通信的代碼，如下：

請點(diǎn)擊輸入圖片描述

其中 vio_read() 函數(shù)中，使用 recv 和 poll 來讀取報(bào)文和做讀取超時(shí)。net_should_retry() 函數(shù)只有在發(fā)生 EINTR 時(shí)才會返回 true。從這段代碼來看是符合測試結(jié)果的，并沒有對讀取進(jìn)行三次重試。只有在讀取操作被系統(tǒng)中斷打斷時(shí)才會重試，但是這個(gè)重試并沒有次數(shù)限制。

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

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

請點(diǎn)擊輸入圖片描述

這個(gè)版本的 MySQL api 的讀寫超時(shí)是直接使用的 setsockopt 設(shè)置的。第一次循環(huán)，在 A 點(diǎn)發(fā)生了第一次超時(shí)（雖然注釋寫的非阻塞，但是客戶端的連接始終是阻塞模式的）。然后在 B 點(diǎn)將該 socket 設(shè)置為阻塞模式，C 點(diǎn)這里重置 retry 次數(shù)。由于設(shè)置了 alarm 第二次以后的循環(huán)會直接進(jìn)入 D 點(diǎn)的這個(gè)分支，并且判斷循環(huán)次數(shù)。作為客戶端時(shí)net-retry_count 始終是 1，所以重試了兩次，共計(jì)進(jìn)行了 3 次 vioread 后從 E 點(diǎn)退出函數(shù)。

由上面的分析可知，MySQL 文檔對于該參數(shù)的描述已經(jīng)過時(shí)，現(xiàn)在的 MYSQL_OPT_READ_TIMEOUT 并不會出現(xiàn)三倍超時(shí)的問題。而 Bug #31163 中的處理結(jié)果也是將文檔中該參數(shù)的描述更新為實(shí)際讀取超時(shí)時(shí)間是設(shè)定時(shí)間的三倍。也許是 MySQL 的維護(hù)者們在后續(xù)版本更新時(shí)忘記更新文檔吧。

mysql連接超時(shí)的問題

出現(xiàn)該問題的主要原因是：Mysql server服務(wù)器超時(shí)，并且關(guān)閉了與客戶端的連接導(dǎo)致的。

默認(rèn)情況下，如果在8小時(shí)沒有對mysql進(jìn)行查詢請求的話，服務(wù)器就會自動(dòng)斷開連接?？梢酝ㄟ^修改全局變量 wait_timeout和interactive_timeout兩個(gè)變量的值來進(jìn)行修改。

接著退出mysql命令行后，重載下mysql

再進(jìn)來看兩個(gè)變量都已經(jīng)更改成功

摘錄自： Mysql server出現(xiàn)“Mysql server has gone away”的錯(cuò)誤的解決方式