前言

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

一、全局鎖

全局鎖的介紹以及使用

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

FLUSH TABLES WITH READ LOCK ;

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

UNLOCK TABLES ;

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

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

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

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

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

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

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

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

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

加鎖和其他方法對比

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

set global readonly=true;

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

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

二、表鎖

表鎖的介紹以及使用

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

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

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

解鎖的語句是：

UNLOCK TABLES ;

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

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

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

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

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

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

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

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

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

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

最新評論