C3p0連接mysql，超時(shí)問(wèn)題

C3P0連接池連接mysql有時(shí)會(huì)出現(xiàn)如下錯(cuò)誤：

成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供永興企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)、H5頁(yè)面制作、小程序制作等業(yè)務(wù)。10年已為永興眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

這是C3P0配置的超時(shí)時(shí)間和mysql超時(shí)時(shí)間不一致導(dǎo)致的，C3P0為60秒超時(shí)，mysql為30秒超時(shí)，在30-60之間的時(shí)間mysql已經(jīng)斷開(kāi)連接，而C3P0還維持連接，再次發(fā)送請(qǐng)求就會(huì)報(bào)上面的錯(cuò)誤。

解決方法：

1、修改C3P0的maxIdleTime參數(shù)為30。

2、修改mysql的wait_timeout參數(shù)為60秒。不停機(jī)狀態(tài)下進(jìn)入mysql命令行，執(zhí)行set global wait_timeout=60;

如何配置MySQL數(shù)據(jù)庫(kù)超時(shí)設(shè)置

大規(guī)模多線程操作事務(wù)的時(shí)候，有時(shí)候打開(kāi)一個(gè)鏈接，會(huì)進(jìn)行等待，這時(shí)候如果數(shù)據(jù)庫(kù)的超時(shí)時(shí)間設(shè)置的過(guò)短，就可能會(huì)出現(xiàn)，數(shù)據(jù)鏈接自動(dòng)被釋放，當(dāng)然設(shè)置過(guò)大也不好，慢SQL或其他因素引起的鏈接過(guò)長(zhǎng)，導(dǎo)致整個(gè)系統(tǒng)被拖慢，甚至掛掉。SO，適當(dāng)?shù)脑O(shè)置超時(shí)時(shí)間。設(shè)置方法：

SHOW GLOBAL VARIABLES LIKE '%timeout%'

SET GLOBAL wait_timeout=10000

網(wǎng)頁(yè)鏈接

MySql執(zhí)行超時(shí)怎么設(shè)置

MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客戶端中用來(lái)設(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.

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

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

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

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

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

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

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

請(qǐng)點(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)會(huì)直接進(jìn)入 D 點(diǎn)的這個(gè)分支，并且判斷循環(huán)次數(shù)。作為客戶端時(shí)net-retry_count 始終是 1，所以重試了兩次，共計(jì)進(jìn)行了 3 次 vioread 后從 E 點(diǎn)退出函數(shù)。

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

mysql怎么設(shè)置超時(shí)時(shí)間

　　MySQL超時(shí)時(shí)間設(shè)置：使用Druid可以配置。

具體設(shè)置方法，代碼如下：

!-- 超過(guò)時(shí)間限制是否回收 --

property name="removeAbandoned" value="true" /

!-- 超時(shí)時(shí)間；單位為秒。180秒=3分鐘 --

property name="removeAbandonedTimeout" value="180" /

!-- 關(guān)閉abanded連接時(shí)輸出錯(cuò)誤日志 --

property name="logAbandoned" value="true" /