前言

對(duì)mysql鎖的總結(jié)學(xué)習(xí)，本文將圍繞，加鎖的概念，加鎖的應(yīng)用場(chǎng)景和優(yōu)化，以及不加鎖會(huì)導(dǎo)致的問(wèn)題這些方向進(jìn)行總結(jié)學(xué)習(xí)。mysql的全局鎖和表鎖是本文的重點(diǎn)

一、全局鎖

全局鎖的介紹以及使用

全局鎖就是對(duì)整個(gè)數(shù)據(jù)庫(kù)實(shí)例進(jìn)行加鎖。
MySQL提供了一個(gè)加全局讀鎖的方法，如下：
全局讀鎖定：

FLUSH TABLES WITH READ LOCK ;

執(zhí)行了命令之后所有庫(kù)所有表都被鎖定只讀，解鎖：

UNLOCK TABLES ;

加了全局讀鎖之后，整個(gè)數(shù)據(jù)庫(kù)都處于只讀的狀態(tài)，當(dāng)其他線程有數(shù)據(jù)更新語(yǔ)句（數(shù)據(jù)的增刪改）、數(shù)據(jù)定義語(yǔ)句（包括建表、修改表結(jié)構(gòu)等）和更新事務(wù)的提交語(yǔ)句都將會(huì)被阻塞。

全局鎖的應(yīng)用場(chǎng)景

了解了全局鎖的基本概念后，心想全局鎖的鎖粒度這么大，效率肯定特別低，應(yīng)該很少使用吧。但是開(kāi)發(fā)者設(shè)計(jì)出來(lái)這個(gè)，肯定有它的使用場(chǎng)景啊。接下來(lái)我們看下:
通過(guò)學(xué)習(xí)了解到，全局鎖最經(jīng)典最常用的場(chǎng)景是用做全庫(kù)邏輯備份 （就是把整個(gè)庫(kù)的每個(gè)表select出來(lái)存放成文本）
把整個(gè)數(shù)據(jù)庫(kù)都鎖住，不能有更新操作，想想都危險(xiǎn)，鎖的粒度太大了。
比如：
如果在用戶訪問(wèn)高峰期，這期間需要數(shù)據(jù)庫(kù)的有關(guān)表進(jìn)行更新操作。這是如果你備份整個(gè)庫(kù)是在主庫(kù)上備份，那么備份期間都不能執(zhí)行更新操作，這是業(yè)務(wù)基本上就得停擺，影響用戶體驗(yàn)。而如果你選擇在從庫(kù)上備份，那么備份期間從庫(kù)不能執(zhí)行主庫(kù)同步過(guò)來(lái)的binlog，會(huì)導(dǎo)致主從延遲。

此時(shí)，你肯定想那加鎖這么麻煩危險(xiǎn)，那還不如不加鎖呢。如果不加鎖會(huì)導(dǎo)致什么后果呢

不加鎖導(dǎo)致的危害

這里我舉個(gè)簡(jiǎn)單的購(gòu)物例子，你就瞬間清楚了。
比如，購(gòu)物。我在某網(wǎng)站上買了一件商品，同時(shí)維護(hù)這網(wǎng)站的也準(zhǔn)備發(fā)起一個(gè)數(shù)據(jù)庫(kù)的邏輯備份。
如果時(shí)間順序上是先備份我們用戶的賬號(hào)余額表，然后用戶購(gòu)買，然后備份用戶商品表。
此時(shí)，會(huì)出現(xiàn)什么問(wèn)題呢。結(jié)果會(huì)發(fā)現(xiàn)，我們用戶的賬號(hào)余額沒(méi)減少，但是多了件購(gòu)買的商品。這也是不是感覺(jué)挺好，我們用戶賺大了啊。不過(guò)如果反過(guò)來(lái)呢，那我們豈不是虧大了。

反觀，會(huì)出現(xiàn)這么一個(gè)現(xiàn)象的原因是什么，其實(shí)就是備份的庫(kù)，備份的庫(kù)中的表不是一個(gè)邏輯時(shí)間點(diǎn)的，即前后沒(méi)有一致性。

提到一致性，我們會(huì)想到那不直接在可重讀隔離級(jí)別下開(kāi)啟一個(gè)事務(wù)，進(jìn)行數(shù)據(jù)邏輯備份不就好了嗎，那豈不是比加鎖好。

想法挺好的，但是也需要系統(tǒng)支持啊。比如像MyISAM這種不支持事務(wù)的引擎，只能通過(guò)FTWRL方法了。

加鎖和其他方法對(duì)比

通過(guò)上面可以知道，整個(gè)庫(kù)進(jìn)行備份，就是先把整個(gè)庫(kù)通過(guò)加全局讀鎖，把整個(gè)庫(kù)設(shè)置成只讀狀態(tài)。
此時(shí)，你肯定會(huì)想，把整個(gè)庫(kù)設(shè)置成只讀狀態(tài)，我還知道使用如下命令進(jìn)行設(shè)置啊，不必要加鎖啊

set global readonly=true;

確實(shí)，readonly這種方式也可以讓全庫(kù)進(jìn)入只讀狀態(tài)。但是對(duì)于一些特殊情況，如在異常處理機(jī)制上，如果執(zhí)行FTWRL命令之后，客戶端發(fā)生異常斷開(kāi)，那么MySQL會(huì)自動(dòng)釋放這個(gè)全局鎖，整個(gè)庫(kù)回到可以正常更新的狀態(tài)，而將這個(gè)庫(kù)設(shè)置為readonly之后，如果客戶端發(fā)生異常，則數(shù)據(jù)庫(kù)就會(huì)一直保持readonly狀態(tài)，這樣會(huì)導(dǎo)致整個(gè)庫(kù)長(zhǎng)時(shí)間處于不可寫(xiě)狀態(tài)；所以還是建議使用全局鎖比較合適

了解完了全局鎖，接下來(lái)我們?cè)賮?lái)學(xué)習(xí)以下表鎖

二、表鎖

表鎖的介紹以及使用

MySQL里面表級(jí)別的鎖有兩種：一種是表鎖，一種是元數(shù)據(jù)鎖（meta data lock，MDL）。

對(duì)于表鎖，加鎖的語(yǔ)句是：

LOCK TABLES tbl_name ; #不影響其他表的寫(xiě)操作

解鎖的語(yǔ)句是：

UNLOCK TABLES ;

另一類表級(jí)的鎖是 MDL（metadata lock) 。MDL不需要顯式使用，在訪問(wèn)一個(gè)表的時(shí)候會(huì)被自動(dòng)加上。

表鎖的應(yīng)用場(chǎng)景

針對(duì)表鎖，在MySQL發(fā)展初級(jí)階段，沒(méi)有設(shè)計(jì)出更細(xì)粒度的鎖時(shí)，表鎖經(jīng)常被用于處理并發(fā)（InnoDB支持行鎖所以一般不會(huì)使用表鎖）。舉個(gè)例子，如果在某個(gè)線程A中執(zhí)行lock tables t1 read, t2 write;這個(gè)語(yǔ)句，則其他線程寫(xiě)t1、讀寫(xiě)t2的語(yǔ)句都會(huì)被阻塞。同時(shí)，線程A在執(zhí)行unlock table之前，也只能執(zhí)行讀t1、讀寫(xiě)t2的操作。連寫(xiě)t1都不允許，自然也不能訪問(wèn)其他表。

對(duì)于MDL鎖，是訪問(wèn)一個(gè)表的時(shí)候自動(dòng)加上的。為什么呢，這也是因?yàn)?strong>時(shí)間邏輯點(diǎn)的不同。比如，如果一個(gè)查詢正在遍歷一個(gè)表中的數(shù)據(jù)，而在此執(zhí)行期間另一個(gè)線程對(duì)這個(gè)表結(jié)構(gòu)做變更，刪了一列，那么查詢線程拿到的結(jié)果跟表結(jié)構(gòu)對(duì)不上，就會(huì)出錯(cuò)。為此，為了解決這些問(wèn)題。當(dāng)對(duì)一個(gè)表做增刪改查操作的時(shí)候，加MDL讀鎖；要對(duì)表做結(jié)構(gòu)變更操作的時(shí)候，加MDL寫(xiě)鎖。

為此需要注意的還有一點(diǎn)，并不是系統(tǒng)默認(rèn)為每一訪問(wèn)表的操作自動(dòng)添加了MDL鎖就會(huì)萬(wàn)事大吉。比如，對(duì)于一個(gè)表t執(zhí)行如下的操作：

session A先啟動(dòng)，對(duì)表t加一個(gè)MDL讀鎖
因?yàn)閟ession B需要的也是讀鎖，可以正常執(zhí)行
因?yàn)閟ession A的MDL讀鎖還沒(méi)有釋放，而session C需要MDL寫(xiě)鎖，因此會(huì)被阻塞
session C之后的所有要對(duì)表申請(qǐng)的讀鎖頁(yè)會(huì)被session C阻塞，最終導(dǎo)致這個(gè)表完全不可讀寫(xiě)
此時(shí)如果對(duì)這個(gè)表的查詢比較頻繁，并且客戶端也有重試機(jī)制，那么這個(gè)庫(kù)的線程很快就會(huì)爆滿

造成這個(gè)問(wèn)題的原因是，事務(wù)中的MDL鎖，在執(zhí)行語(yǔ)句的時(shí)候開(kāi)始申請(qǐng)，但是語(yǔ)句結(jié)束后并不會(huì)馬上釋放，而是等到整個(gè)事務(wù)提交后再釋放。

因此，了解了這個(gè)問(wèn)題，以及這個(gè)問(wèn)題出現(xiàn)的原因。
那么我們?nèi)绾谓鉀Q安全的給表加字段呢

首先要解決長(zhǎng)事務(wù)，畢竟事務(wù)不提交，就會(huì)一直占著MDL鎖。。因此如果要做DDL變更表的時(shí)候，查到剛好有長(zhǎng)事務(wù)在執(zhí)行，可以考慮暫停DDL操作或者kill掉長(zhǎng)事務(wù)
如果要操作的表是個(gè)熱點(diǎn)表，請(qǐng)求比較頻繁，此時(shí)如果采用kill，那么新的請(qǐng)求立馬就來(lái)了，未必管用。因此比較合適的操作是：在alter table語(yǔ)句里面設(shè)定等待時(shí)間，如果在這個(gè)指定的等待時(shí)間里面能夠拿到MDL寫(xiě)鎖最好，拿不到也不要阻塞后面的業(yè)務(wù)語(yǔ)句，先放棄。之后再通過(guò)重試命令重復(fù)這個(gè)過(guò)程。

到此這篇關(guān)于MySQL的鎖機(jī)制之全局鎖和表鎖的實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)MySQL 全局鎖和表鎖內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論