深入理解MySQL數(shù)據(jù)庫(kù)各種鎖（總結(jié)）

MyISAM和InnoDB存儲(chǔ)引擎使用的鎖：

成都創(chuàng)新互聯(lián)公司專(zhuān)注為客戶(hù)提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、羅山網(wǎng)絡(luò)推廣、成都小程序開(kāi)發(fā)、羅山網(wǎng)絡(luò)營(yíng)銷(xiāo)、羅山企業(yè)策劃、羅山品牌公關(guān)、搜索引擎seo、人物專(zhuān)訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；成都創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供羅山建站搭建服務(wù)，24小時(shí)服務(wù)熱線：18982081108，官方網(wǎng)址：www.cdcxhl.com

封鎖粒度小：

由于InnoDB存儲(chǔ)引擎支持的是行級(jí)別的鎖，因此意向鎖（因?yàn)橐庀蜴i是表鎖）其實(shí)不會(huì)阻塞除全表掃以外的任何請(qǐng)求。故表級(jí)意向鎖與行級(jí)鎖的兼容性如下所示

參考

參考

行鎖的三種算法：

這條語(yǔ)句阻止其他事務(wù)插入10和20之間的數(shù)字，無(wú)論這個(gè)數(shù)字是否存在。 間隙可以跨越0個(gè)，單個(gè)或多個(gè)索引值。

共享鎖：

排他鎖：

樂(lè)觀鎖：總是假設(shè)最好的情況，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改（天真）， 操作數(shù)據(jù)時(shí)不會(huì)上鎖 ，但是 更新時(shí)會(huì)判斷在此期間有沒(méi)有別的事務(wù)更新這個(gè)數(shù)據(jù)，若被更新過(guò)，則失敗重試 ；適用于讀多寫(xiě)少的場(chǎng)景。

樂(lè)觀鎖的實(shí)現(xiàn)方式 有：

關(guān)閉自動(dòng)提交后，我們需要手動(dòng)開(kāi)啟事務(wù)。

上述就實(shí)現(xiàn)了悲觀鎖，悲觀鎖就是悲觀主義者，它會(huì)認(rèn)為我們?cè)谑聞?wù)A中操作數(shù)據(jù)1的時(shí)候，一定會(huì)有事務(wù)B來(lái)修改數(shù)據(jù)1,所以，在第2步我們將數(shù)據(jù)查詢(xún)出來(lái)后直接加上排它鎖（X）鎖，防止別的事務(wù)來(lái)修改事務(wù)1，直到我們commit后，才釋放了排它鎖。

mysql 的鎖以及間隙鎖

mysql 為并發(fā)事務(wù)同時(shí)對(duì)一條記錄進(jìn)行讀寫(xiě)時(shí)，提出了兩種解決方案：

1）使用 mvcc 的方法，實(shí)現(xiàn)多事務(wù)的并發(fā)讀寫(xiě)，但是這種讀只是“快照讀”，一般讀的是歷史版本數(shù)據(jù)，還有一種是“當(dāng)前讀”，一般加鎖實(shí)現(xiàn)“當(dāng)前讀”，或者 insert、update、delete 也是當(dāng)前讀。

2）使用加鎖的方法，鎖分為共享鎖（讀鎖），排他鎖（寫(xiě)鎖）

快照讀：就是select

當(dāng)前讀：特殊的讀操作，插入/更新/刪除操作，屬于當(dāng)前讀，處理的都是當(dāng)前的數(shù)據(jù)，需要加鎖。

mysql 在 RR 級(jí)別怎么處理幻讀的呢？一般來(lái)說(shuō)，RR 級(jí)別通過(guò) mvcc 機(jī)制，保證讀到低于后面事務(wù)的數(shù)據(jù)。但是 select for update 不會(huì)觸發(fā) mvcc，它是當(dāng)前讀。如果后面事務(wù)插入數(shù)據(jù)并提交，那么在 RR 級(jí)別就會(huì)讀到插入的數(shù)據(jù)。所以，mysql 使用 行鎖 + gap 鎖（簡(jiǎn)稱(chēng) next-key 鎖）來(lái)防止當(dāng)前讀的時(shí)候插入。

Gap Lock在InnoDB的唯一作用就是防止其他事務(wù)的插入操作，以此防止幻讀的發(fā)生。

Innodb自動(dòng)使用間隙鎖的條件：

Mysql中鎖的類(lèi)型有哪些呢？

mysql鎖分為共享鎖和排他鎖，也叫做讀鎖和寫(xiě)鎖。

讀鎖是共享的，可以通過(guò)lock in share mode實(shí)現(xiàn)，這時(shí)候只能讀不能寫(xiě)。

寫(xiě)鎖是排他的，它會(huì)阻塞其他的寫(xiě)鎖和讀鎖。從顆粒度來(lái)區(qū)分，可以分為表鎖和?鎖兩種。

表鎖會(huì)鎖定整張表并且阻塞其他?戶(hù)對(duì)該表的所有讀寫(xiě)操作，?如alter修改表結(jié)構(gòu)的時(shí)候會(huì)鎖表。

?鎖?可以分為樂(lè)觀鎖和悲觀鎖，悲觀鎖可以通過(guò)for update實(shí)現(xiàn)，樂(lè)觀鎖則通過(guò)版本號(hào)實(shí)現(xiàn)。

MySQL數(shù)據(jù)庫(kù)表被鎖、解鎖，刪除事務(wù)

在程序員的職業(yè)生涯中，總會(huì)遇到數(shù)據(jù)庫(kù)表被鎖的情況，前些天就又撞見(jiàn)一次。由于業(yè)務(wù)突發(fā)需求，各個(gè)部門(mén)都在批量操作、導(dǎo)出數(shù)據(jù)，而數(shù)據(jù)庫(kù)又未做讀寫(xiě)分離，結(jié)果就是：數(shù)據(jù)庫(kù)的某張表被鎖了！

用戶(hù)反饋系統(tǒng)部分功能無(wú)法使用，緊急排查，定位是數(shù)據(jù)庫(kù)表被鎖，然后進(jìn)行緊急處理。這篇文章給大家講講遇到類(lèi)似緊急狀況的排查及解決過(guò)程，建議點(diǎn)贊收藏，以備不時(shí)之需。

用戶(hù)反饋某功能頁(yè)面報(bào)502錯(cuò)誤，于是第一時(shí)間看服務(wù)是否正常，數(shù)據(jù)庫(kù)是否正常。在控制臺(tái)看到數(shù)據(jù)庫(kù)CPU飆升，堆積大量未提交事務(wù)，部分事務(wù)已經(jīng)阻塞了很長(zhǎng)時(shí)間，基本定位是數(shù)據(jù)庫(kù)層出現(xiàn)問(wèn)題了。

查看阻塞事務(wù)列表，發(fā)現(xiàn)其中有鎖表現(xiàn)象，本想利用控制臺(tái)直接結(jié)束掉阻塞的事務(wù)，但控制臺(tái)賬號(hào)權(quán)限有限，于是通過(guò)客戶(hù)端登錄對(duì)應(yīng)賬號(hào)將鎖表事務(wù)kill掉，才避免了情況惡化。

下面就聊聊，如果當(dāng)突然面對(duì)類(lèi)似的情況，我們?cè)撊绾尉o急響應(yīng)？

想象一個(gè)場(chǎng)景，當(dāng)然也是軟件工程師職業(yè)生涯中會(huì)遇到的一種場(chǎng)景：原本運(yùn)行正常的程序，某一天突然數(shù)據(jù)庫(kù)的表被鎖了，業(yè)務(wù)無(wú)法正常運(yùn)轉(zhuǎn)，那么我們?cè)撊绾慰焖俣ㄎ皇悄膫€(gè)事務(wù)鎖了表，如何結(jié)束對(duì)應(yīng)的事物？

首先最簡(jiǎn)單粗暴的方式就是：重啟MySQL。對(duì)的，網(wǎng)管解決問(wèn)題的神器——“重啟”。至于后果如何，你能不能跑了，要你自己三思而后行了！

重啟是可以解決表被鎖的問(wèn)題的，但針對(duì)線上業(yè)務(wù)很顯然不太具有可行性。

下面來(lái)看看不用跑路的解決方案：

遇到數(shù)據(jù)庫(kù)阻塞問(wèn)題，首先要查詢(xún)一下表是否在使用。

如果查詢(xún)結(jié)果為空，那么說(shuō)明表沒(méi)在使用，說(shuō)明不是鎖表的問(wèn)題。

如果查詢(xún)結(jié)果不為空，比如出現(xiàn)如下結(jié)果：

則說(shuō)明表（test）正在被使用，此時(shí)需要進(jìn)一步排查。

查看數(shù)據(jù)庫(kù)當(dāng)前的進(jìn)程，看看是否有慢SQL或被阻塞的線程。

執(zhí)行命令：

該命令只顯示當(dāng)前用戶(hù)正在運(yùn)行的線程，當(dāng)然，如果是root用戶(hù)是能看到所有的。

在上述實(shí)踐中，阿里云控制臺(tái)之所以能夠查看到所有的線程，猜測(cè)應(yīng)該使用的就是root用戶(hù)，而筆者去kill的時(shí)候，無(wú)法kill掉，是因?yàn)榈卿浀挠脩?hù)非root的數(shù)據(jù)庫(kù)賬號(hào)，無(wú)法操作另外一個(gè)用戶(hù)的線程。

如果情況緊急，此步驟可以跳過(guò)，主要用來(lái)查看核對(duì)：

如果情況緊急，此步驟可以跳過(guò)，主要用來(lái)查看核對(duì)：

看事務(wù)表INNODB_TRX中是否有正在鎖定的事務(wù)線程，看看ID是否在show processlist的sleep線程中。如果在，說(shuō)明這個(gè)sleep的線程事務(wù)一直沒(méi)有commit或者rollback，而是卡住了，需要手動(dòng)kill掉。

搜索的結(jié)果中，如果在事務(wù)表發(fā)現(xiàn)了很多任務(wù)，最好都kill掉。

執(zhí)行kill命令：

對(duì)應(yīng)的線程都執(zhí)行完kill命令之后，后續(xù)事務(wù)便可正常處理。

針對(duì)緊急情況，通常也會(huì)直接操作第一、第二、第六步。

這里再補(bǔ)充一些MySQL鎖相關(guān)的知識(shí)點(diǎn)：數(shù)據(jù)庫(kù)鎖設(shè)計(jì)的初衷是處理并發(fā)問(wèn)題，作為多用戶(hù)共享的資源，當(dāng)出現(xiàn)并發(fā)訪問(wèn)的時(shí)候，數(shù)據(jù)庫(kù)需要合理地控制資源的訪問(wèn)規(guī)則，而鎖就是用來(lái)實(shí)現(xiàn)這些訪問(wèn)規(guī)則的重要數(shù)據(jù)結(jié)構(gòu)。

根據(jù)加鎖的范圍，MySQL里面的鎖大致可以分成全局鎖、表級(jí)鎖和行鎖三類(lèi)。MySQL中表級(jí)別的鎖有兩種：一種是表鎖，一種是元數(shù)據(jù)鎖（metadata lock，MDL)。

表鎖是在Server層實(shí)現(xiàn)的，ALTER TABLE之類(lèi)的語(yǔ)句會(huì)使用表鎖，忽略存儲(chǔ)引擎的鎖機(jī)制。表鎖通過(guò)lock tables… read/write來(lái)實(shí)現(xiàn)，而對(duì)于InnoDB來(lái)說(shuō)，一般會(huì)采用行級(jí)鎖。畢竟鎖住整張表影響范圍太大了。

另外一個(gè)表級(jí)鎖是MDL（metadata lock），用于并發(fā)情況下維護(hù)數(shù)據(jù)的一致性，保證讀寫(xiě)的正確性，不需要顯式的使用，在訪問(wèn)一張表時(shí)會(huì)被自動(dòng)加上。

常見(jiàn)的一種鎖表場(chǎng)景就是有事務(wù)操作處于：Waiting for table metadata lock狀態(tài)。

MySQL在進(jìn)行alter table等DDL操作時(shí)，有時(shí)會(huì)出現(xiàn)Waiting for table metadata lock的等待場(chǎng)景。

一旦alter table TableA的操作停滯在Waiting for table metadata lock狀態(tài)，后續(xù)對(duì)該表的任何操作（包括讀）都無(wú)法進(jìn)行，因?yàn)樗鼈円矔?huì)在Opening tables的階段進(jìn)入到Waiting for table metadata lock的鎖等待隊(duì)列。如果核心表出現(xiàn)了鎖等待隊(duì)列，就會(huì)造成災(zāi)難性的后果。

通過(guò)show processlist可以看到表上有正在進(jìn)行的操作（包括讀），此時(shí)alter table語(yǔ)句無(wú)法獲取到metadata 獨(dú)占鎖，會(huì)進(jìn)行等待。

通過(guò)show processlist看不到表上有任何操作，但實(shí)際上存在有未提交的事務(wù)，可以在information_schema.innodb_trx中查看到。在事務(wù)沒(méi)有完成之前，表上的鎖不會(huì)釋放，alter table同樣獲取不到metadata的獨(dú)占鎖。

處理方法：通過(guò) select * from information_schema.innodb_trxG, 找到未提交事物的sid，然后kill掉，讓其回滾。

通過(guò)show processlist看不到表上有任何操作，在information_schema.innodb_trx中也沒(méi)有任何進(jìn)行中的事務(wù)。很可能是因?yàn)樵谝粋€(gè)顯式的事務(wù)中，對(duì)表進(jìn)行了一個(gè)失敗的操作（比如查詢(xún)了一個(gè)不存在的字段），這時(shí)事務(wù)沒(méi)有開(kāi)始，但是失敗語(yǔ)句獲取到的鎖依然有效，沒(méi)有釋放。從performance_schema.events_statements_current表中可以查到失敗的語(yǔ)句。

處理方法：通過(guò)performance_schema.events_statements_current找到其sid，kill 掉該session，也可以kill掉DDL所在的session。

總之，alter table的語(yǔ)句是很危險(xiǎn)的（核心是未提交事務(wù)或者長(zhǎng)事務(wù)導(dǎo)致的），在操作之前要確認(rèn)對(duì)要操作的表沒(méi)有任何進(jìn)行中的操作、沒(méi)有未提交事務(wù)、也沒(méi)有顯式事務(wù)中的報(bào)錯(cuò)語(yǔ)句。

如果有alter table的維護(hù)任務(wù)，在無(wú)人監(jiān)管的時(shí)候運(yùn)行，最好通過(guò)lock_wait_timeout設(shè)置好超時(shí)時(shí)間，避免長(zhǎng)時(shí)間的metedata鎖等待。

關(guān)于MySQL的鎖表其實(shí)還有很多其他場(chǎng)景，我們?cè)趯?shí)踐的過(guò)程中盡量避免鎖表情況的發(fā)生，當(dāng)然這需要一定經(jīng)驗(yàn)的支撐。但更重要的是，如果發(fā)現(xiàn)鎖表我們要能夠快速的響應(yīng)，快速的解決問(wèn)題，避免影響正常業(yè)務(wù)，避免情況進(jìn)一步惡化。所以，本文中的解決思路大家一定要收藏或記憶一下，做到有備無(wú)患，避免突然狀況下抓瞎。