前言

閱讀本文，你可以收獲：

• 線上問題定位和排查思路
• Docker 和 MySQL 相關(guān)命令使用
• MySQL 鎖和索引相關(guān)知識(shí)學(xué)習(xí)

現(xiàn)象

開發(fā)環(huán)境一個(gè)微服務(wù)模塊所有接口請(qǐng)求報(bào)錯(cuò)，對(duì)應(yīng)頁面無法訪問。其他未涉及到該模塊的接口和頁面訪問正常。

最近未更新過該服務(wù)，之前該服務(wù)也沒有發(fā)生過不可用的情況。

錯(cuò)誤排查

根據(jù)所觀察到的現(xiàn)象，加上簡(jiǎn)單思考判斷，可以確定是單個(gè)服務(wù)出現(xiàn)故障，而且大概率是服務(wù)運(yùn)行一段時(shí)間后出現(xiàn)的問題，具體原因尚不清楚。

查看日志

日志是我們排查問題時(shí)的第一個(gè)入口，根據(jù)日志信息，可以進(jìn)一步定位問題。

登陸到遠(yuǎn)程服務(wù)器，執(zhí)行如下命令，查看容器日志。

docker ps // 查看容器 id
docker logs -f --tail 2000 容器id     // 查看容器最后2000行日志

日志中顯示的報(bào)錯(cuò)信息如下

org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms.

報(bào)錯(cuò)信息顯示連接池請(qǐng)求數(shù)據(jù)庫連接超時(shí)，有幾種可能的原因會(huì)導(dǎo)致該錯(cuò)誤：

1、網(wǎng)絡(luò)或數(shù)據(jù)庫故障，這也是最先被排除的原因，因?yàn)槠渌⒎?wù)運(yùn)行正常，說明網(wǎng)絡(luò)連接沒問題、數(shù)據(jù)庫也沒故障宕機(jī)。

2、連接池配置不足，因?yàn)闃I(yè)務(wù)請(qǐng)求量并不大，也查看了連接池配置，并無問題，因此這種原因可能性較小，但不排除；

3、連接池最大活躍連接數(shù)達(dá)到了上限，連接池的配置無問題，但因?yàn)楫惓Ｔ驅(qū)е铝诉B接數(shù)達(dá)到了上限，這個(gè)原因可能性相對(duì)來說最高，但還要觀察數(shù)據(jù)庫的運(yùn)行情況，收集更多信息才能進(jìn)行下一步判斷。

連接數(shù)據(jù)庫

information_schema 數(shù)據(jù)庫下有幾張表可以幫助我們收集數(shù)據(jù)庫的運(yùn)行情況。

查看當(dāng)前數(shù)據(jù)庫運(yùn)行的所有事務(wù)，確認(rèn)是否有大事務(wù)長(zhǎng)時(shí)間持有數(shù)據(jù)庫連接。表 INNODB_TRX 記錄了當(dāng)前正在運(yùn)行的事務(wù)信息，包括事務(wù) ID、事務(wù)狀態(tài)、事務(wù)開始時(shí)間、鎖等待時(shí)間等。

// 查看當(dāng)前運(yùn)行的所有事務(wù)
select * from information_schema.INNODB_TRX;

查詢結(jié)果如圖。發(fā)現(xiàn)大量事務(wù)處于 LOCK WAIT 狀態(tài)，只有一個(gè)事務(wù)處于 RUNNING 狀態(tài)，被阻塞的事務(wù)都是在執(zhí)行更新同一張表中的記錄操作。

進(jìn)一步確認(rèn)，查看當(dāng)前數(shù)據(jù)庫出現(xiàn)的鎖信息。表 INNODB_LOCKS 記錄了當(dāng)前被鎖定的對(duì)象以及相關(guān)的鎖信息，包括事務(wù) ID、鎖類型、鎖定模式、鎖定對(duì)象等。注意 MySQL 8.0 版本之后沒有此表。

// 當(dāng)前出現(xiàn)的鎖
select * from infromation_schema.INNODB_LOCKS;
// MySQL 8.0之后執(zhí)行下面語句
select * from performance_schema.data_locks;

查詢結(jié)果如圖。鎖的記錄數(shù)正好對(duì)應(yīng)上面查詢的事務(wù)數(shù)，并且都持有 X 鎖（排他鎖）

問題定位&解決

至此，錯(cuò)誤產(chǎn)生的原因已經(jīng)明確：數(shù)據(jù)庫中大量事務(wù)占用連接資源并處于阻塞狀態(tài)，連接池最大連接數(shù)達(dá)到上限，無法獲取新的連接來處理請(qǐng)求。只要找到事務(wù)阻塞的原因并且解決，那么問題就解決了。

查看事務(wù)執(zhí)行的 SQL 語句和對(duì)應(yīng)的表結(jié)構(gòu)，發(fā)現(xiàn) where 條件后的字段沒有添加索引。更新導(dǎo)致了鎖表?。?！

解決：為字段加上索引（一個(gè)索引引發(fā)這么大問題?。?/p>

alter table 表名 add index 索引名(列名)

問題

為什么服務(wù)運(yùn)行了一段時(shí)間后，出現(xiàn)了這個(gè)問題？

服務(wù)剛運(yùn)行的時(shí)候，連接池資源是夠用的，業(yè)務(wù)也能正常使用。但是這條更新語句調(diào)用頻繁，會(huì)不斷產(chǎn)生新連接執(zhí)行更新操作，然而同一時(shí)刻只能有一個(gè)事務(wù)執(zhí)行（鎖表），其他事務(wù)都會(huì)阻塞。阻塞的事務(wù)越來越多，事務(wù)又占有連接資源，可用的連接數(shù)越來越少，服務(wù)運(yùn)行一段時(shí)間之后，就出現(xiàn)了問題。

update 沒加索引，為什么會(huì)鎖表？

數(shù)據(jù)庫的事務(wù)隔離級(jí)別是“可重復(fù)讀”。在 InnoDB 事務(wù)中，對(duì)記錄加鎖的基本單位是 next-key 鎖（記錄鎖 + 間隙鎖）。當(dāng) update 語句的 where 條件沒有使用索引時(shí)，需要掃描整個(gè)表來找到滿足 WHERE 條件的記錄，于是就會(huì)對(duì)所有記錄加上 next-key 鎖，相當(dāng)于把整個(gè)表鎖住了。

update 加上索引，能避免鎖表嗎？

如果條件字段是唯一索引，next-key 鎖會(huì)退化成記錄鎖，只會(huì)鎖一條記錄，不會(huì)鎖表。

如果條件字段不是唯一索引，得看這條語句在執(zhí)行過程中，優(yōu)化器最終選擇的是索引掃描，還是全表掃描，如果走了全表掃描，同樣還是會(huì)鎖表。

到此這篇關(guān)于mysql中Update未加索引導(dǎo)致的微服務(wù)模塊不可用的文章就介紹到這了,更多相關(guān)mysql Update未加索引內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論