mysql數(shù)據(jù)庫(kù)響應(yīng)超時(shí)怎么辦

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

成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),全南企業(yè)網(wǎng)站建設(shè),全南品牌網(wǎng)站建設(shè),網(wǎng)站定制,全南網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷(xiāo),網(wǎng)絡(luò)優(yōu)化,全南網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

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 的讀寫(xiě)超時(shí)是直接使用的 setsockopt 設(shè)置的。第一次循環(huán)，在 A 點(diǎn)發(fā)生了第一次超時(shí)（雖然注釋寫(xiě)的非阻塞，但是客戶端的連接始終是阻塞模式的）。然后在 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í)關(guān)閉

經(jīng) 過(guò)這樣處理后，可以非常有效的解決MySQL server has gone away這樣的問(wèn)題，而且不會(huì)對(duì)系統(tǒng)造成額外的開(kāi)銷(xiāo)。 今天遇到類(lèi)似的情景，MySQL只是冷冷的說(shuō)：MySQL server has gone away。 大概瀏覽了一下，主要可能是因?yàn)橐韵聨追N原因： 一種可能是發(fā)送的SQL語(yǔ)句太長(zhǎng)，以致超過(guò)了max_allowed_packet的大小，如果是這種原因，你只要修改my.cnf，加大max_allowed_packet的值即可。 還有一種可能是因?yàn)槟承┰驅(qū)е鲁瑫r(shí)，比如說(shuō)程序中獲取數(shù)據(jù)庫(kù)連接時(shí)采用了Singleton的做法，雖然多次連接數(shù)據(jù)庫(kù)，但其實(shí)使用的都是同一個(gè)連接，而且程序中某兩次操作數(shù)據(jù)庫(kù)的間隔時(shí)間超過(guò)了wait_timeout（SHOW STATUS能看到此設(shè)置），那么就可能出現(xiàn)問(wèn)題。最簡(jiǎn)單的處理方式就是把wait_timeout改大，當(dāng)然你也可以在程序里時(shí)不時(shí)順手mysql_ping()一下，這樣MySQL就知道它不是一個(gè)人在戰(zhàn)斗。 解決MySQL server has gone away 1、應(yīng)用程序（比如PHP）長(zhǎng)時(shí)間的執(zhí)行批量的MYSQL語(yǔ)句。最常見(jiàn)的就是采集或者新舊數(shù)據(jù)轉(zhuǎn)化。

mysql數(shù)據(jù)庫(kù)檢查表經(jīng)常超時(shí)，怎樣解決

對(duì)查詢中經(jīng)常作為查詢條件的字段增加索引，比如說(shuō)

select?*?from?table1?where?name?like?'xxx'?and?create_time??'2013-06-01'

這里就可以為name 和 create_time分別創(chuàng)建索引；

ALTER?TABLE?table1?ADD?INDEX?`ind_CreateTime`?(`create_time`);

ALTER?TABLE?table1?ADD?INDEX?`ind_name`?(`name`);

2. 優(yōu)化導(dǎo)致慢查詢的SQL語(yǔ)句?？梢詫⒁粭l查詢分解為多條小范圍的查詢，將結(jié)果union在一起。盡量減少在where 條件中使用 like or between等運(yùn)算符

mysql數(shù)據(jù)庫(kù)表鎖等待超時(shí)怎么解決

當(dāng)你開(kāi)始執(zhí)行一個(gè) ALTER ，而你遇到了可怕的“元數(shù)據(jù)鎖定等待”，我敢肯定你一定遇見(jiàn)過(guò)。我最近遇到了一個(gè)案例，其中被更改的表要執(zhí)行一個(gè)很小范圍的更新（100行）。ALTER 在負(fù)載測(cè)試期間一直等待了幾個(gè)小時(shí)。在停止負(fù)載測(cè)試后，ALTER 按預(yù)期在不到一秒的時(shí)間內(nèi)就完成了。那么這里發(fā)生了什么？

檢查外鍵

每當(dāng)有奇數(shù)次鎖定時(shí)，我的第一直覺(jué)就是檢查外鍵。當(dāng)然這張表有一些外鍵引用了一個(gè)更繁忙的表。但是這種行為似乎仍然很奇怪。對(duì)表運(yùn)行 ALTER 時(shí)，會(huì)針對(duì)子表請(qǐng)求一個(gè) SHARED_UPGRADEABLE 元數(shù)據(jù)鎖。還有針對(duì)父級(jí)的 SHARED_READ_ONLY 元數(shù)據(jù)鎖。

我們來(lái)看看如何根據(jù)文檔獲取元數(shù)據(jù)鎖定[1]：

如果給定鎖定有多個(gè)服務(wù)器，則首先滿足最高優(yōu)先級(jí)鎖定請(qǐng)求，并且與 max_write_lock_count系統(tǒng)變量有關(guān)。寫(xiě)鎖定請(qǐng)求的優(yōu)先級(jí)高于讀取鎖定請(qǐng)求。

[1]：

請(qǐng)務(wù)必注意鎖定順序是序列化的：語(yǔ)句逐個(gè)獲取元數(shù)據(jù)鎖，而不是同時(shí)獲取，并在此過(guò)程中執(zhí)行死鎖檢測(cè)。

通常在考慮隊(duì)列時(shí)考慮先進(jìn)先出。如果我發(fā)出以下三個(gè)語(yǔ)句（按此順序），它們將按以下順序完成：

1. INSERT INTO parent2. ALTER TABLE child3. INSERT INTO parent

但是當(dāng)子 ALTER 語(yǔ)句請(qǐng)求對(duì)父進(jìn)行讀取鎖定時(shí)，盡管排序，但兩個(gè)插入將在 ALTER 之前完成。以下是可以演示此示例的示例場(chǎng)景：

數(shù)據(jù)初始化：

CREATE TABLE `parent` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`val` varchar(10) DEFAULT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB;

CREATE TABLE `child` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`parent_id` int(11) DEFAULT NULL,

`val` varchar(10) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `idx_parent` (`parent_id`),

CONSTRAINT `fk_parent` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION

) ENGINE=InnoDB;

INSERT INTO `parent` VALUES (1, "one"), (2, "two"), (3, "three"), (4, "four");

Session 1:

start transaction;update parent set val = "four-new" where id = 4;

Session 2:

alter table child add index `idx_new` (val);

Session 3:

start transaction;update parent set val = "three-new" where id = 3;

此時(shí)，會(huì)話 1 具有打開(kāi)的事務(wù)，并且處于休眠狀態(tài)，并在父級(jí)上授予寫(xiě)入元數(shù)據(jù)鎖定。 會(huì)話 2 具有在子級(jí)上授予的可升級(jí)（寫(xiě)入）鎖定，并且正在等待父級(jí)的讀取鎖定。最后會(huì)話 3 具有針對(duì)父級(jí)的授權(quán)寫(xiě)入鎖定：

mysql select * from performance_schema.metadata_locks;+-------------+-------------+-------------------+---------------+-------------+| OBJECT_TYPE | OBJECT_NAME | LOCK_TYPE ? ? ? ? | LOCK_DURATION | LOCK_STATUS |+-------------+-------------+-------------------+---------------+-------------+| TABLE ? ? ? | child ? ? ? | SHARED_UPGRADABLE | TRANSACTION ? | GRANTED ? ? | - ALTER (S2)| TABLE ? ? ? | parent ? ? ?| SHARED_WRITE ? ? ?| TRANSACTION ? | GRANTED ? ? | - UPDATE (S1)| TABLE ? ? ? | parent ? ? ?| SHARED_WRITE ? ? ?| TRANSACTION ? | GRANTED ? ? | - UPDATE (S3)| TABLE ? ? ? | parent ? ? ?| SHARED_READ_ONLY ?| STATEMENT ? ? | PENDING ? ? | - ALTER (S2)+-------------+-------------+-------------------+---------------+-------------+

請(qǐng)注意，具有掛起鎖定狀態(tài)的唯一會(huì)話是會(huì)話 2（ALTER）。會(huì)話 1 和會(huì)話 3 （分別在 ALTER 之前和之后發(fā)布）都被授予了寫(xiě)鎖。排序失敗的地方是在會(huì)話 1 上發(fā)生提交的時(shí)候。在考慮有序隊(duì)列時(shí)，人們會(huì)期望會(huì)話 2 獲得鎖定，事情就會(huì)繼續(xù)進(jìn)行。但是，由于元數(shù)據(jù)鎖定系統(tǒng)的優(yōu)先級(jí)性質(zhì)，會(huì)話 3 具有鎖定，會(huì)話 2 仍然等待。

如果另一個(gè)寫(xiě)入會(huì)話進(jìn)入并啟動(dòng)新事務(wù)并獲取針對(duì)父表的寫(xiě)鎖定，則即使會(huì)話 3 完成，ALTER 仍將被阻止。

只要我保持一個(gè)對(duì)父表打開(kāi)元數(shù)據(jù)鎖定的活動(dòng)事務(wù)，子表上的 ALTER 將永遠(yuǎn)不會(huì)完成。更糟糕的是，由于子表上的寫(xiě)鎖定成功（但是完整語(yǔ)句正在等待獲取父讀鎖定），所以針對(duì)子表的所有傳入讀取請(qǐng)求都將被阻止！

另外，請(qǐng)考慮一下您通常如何對(duì)無(wú)法完成的語(yǔ)句進(jìn)行故障排除。您查看已經(jīng)打開(kāi)較長(zhǎng)時(shí)間的事務(wù)（在進(jìn)程列表和 InnoDB 狀態(tài)中）。但由于阻塞線程現(xiàn)在比 ALTER 線程更年輕，因此您將看到的最舊的事務(wù)/線程是 ALTER 。

這正是這種情況下發(fā)生的情況。在準(zhǔn)備發(fā)布時(shí)，我們的客戶端正在運(yùn)行 ALTER 語(yǔ)句并結(jié)合負(fù)載測(cè)試（一種非常好的做法！）以確保順利發(fā)布。問(wèn)題是負(fù)載測(cè)試保持對(duì)父表打開(kāi)一個(gè)活動(dòng)的寫(xiě)事務(wù)。這并不是說(shuō)它只是一直在寫(xiě)，而是有多個(gè)線程，一個(gè)總是活躍的。 這阻止了 ALTER 完成并阻止對(duì)相對(duì)靜態(tài)的子表的隨后的讀請(qǐng)求。

幸運(yùn)的是，這個(gè)問(wèn)題有一個(gè)解決方案（除了從設(shè)計(jì)模式中驅(qū)逐外鍵）。變量?max_write_lock_count[2]?可用于允許在寫(xiě)入鎖定之后在讀取鎖定之前授予讀取鎖定連續(xù)寫(xiě)鎖。默認(rèn)情況下，此變量設(shè)置為 18446744073709551615，如果你對(duì)該表發(fā)出 10,000 次寫(xiě)入/秒，那么你的讀將被鎖定 5800 萬(wàn)年……

MySQL連接超時(shí)自動(dòng)斷開(kāi)連接應(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ù)是不提供類(lèi)似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默認(rèn)超時(shí)時(shí)間問(wèn)題怎么處理

第一種途徑使用命令行set

@@GLOBAL.wait_timeout=1814400

這種方式是一種臨時(shí)方法，重啟服務(wù)就會(huì)返回默認(rèn)值了。

第二種途徑修改my.ini配置文件

[mysqld]

wait_timeout=31536000

interactive_timeout=31536000

在mysqld下面添加以上兩行，后面的數(shù)字是時(shí)間

首先服務(wù)中找到mysql，然后右鍵屬性，在可執(zhí)行文件的路徑中，使勁向后拖動(dòng)鼠標(biāo)就可以看到my.ini的文件了