前言

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

一、全局鎖

全局鎖的介紹以及使用

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

FLUSH TABLES WITH READ LOCK ;

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

UNLOCK TABLES ;

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

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

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

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

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

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

反觀，會出現(xiàn)這么一個現(xiàn)象的原因是什么，其實就是備份的庫，備份的庫中的表不是一個邏輯時間點的，即前后沒有一致性。

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

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

加鎖和其他方法對比

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

set global readonly=true;

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

了解完了全局鎖，接下來我們再來學(xué)習(xí)以下表鎖

二、表鎖

表鎖的介紹以及使用

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

對于表鎖，加鎖的語句是：

LOCK TABLES tbl_name ; #不影響其他表的寫操作

解鎖的語句是：

UNLOCK TABLES ;

另一類表級的鎖是 MDL（metadata lock) 。MDL不需要顯式使用，在訪問一個表的時候會被自動加上。

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

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

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

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

session A先啟動，對表t加一個MDL讀鎖
因為session B需要的也是讀鎖，可以正常執(zhí)行
因為session A的MDL讀鎖還沒有釋放，而session C需要MDL寫鎖，因此會被阻塞
session C之后的所有要對表申請的讀鎖頁會被session C阻塞，最終導(dǎo)致這個表完全不可讀寫
此時如果對這個表的查詢比較頻繁，并且客戶端也有重試機(jī)制，那么這個庫的線程很快就會爆滿

造成這個問題的原因是，事務(wù)中的MDL鎖，在執(zhí)行語句的時候開始申請，但是語句結(jié)束后并不會馬上釋放，而是等到整個事務(wù)提交后再釋放。

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

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

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

最新評論