本篇文章給大家?guī)砹岁P(guān)于mysql的相關(guān)知識，其中主要介紹了關(guān)于全局鎖的相關(guān)問題，全局鎖就是對整個(gè)數(shù)據(jù)庫加鎖。當(dāng)我們對數(shù)據(jù)庫加了讀鎖之后，其他任何的請求都不能對數(shù)據(jù)庫加寫鎖了，下面一起來看一下，希望對大家有幫助。

推薦學(xué)習(xí)：mysql視頻教程

數(shù)據(jù)庫設(shè)計(jì)的初衷是處理并發(fā)問題的，作為多用戶共享的資源，當(dāng)出現(xiàn)并發(fā)訪問時(shí)，數(shù)據(jù)庫需要合理地控制資源的訪問規(guī)則。而鎖就是用來實(shí)現(xiàn)這個(gè)訪問規(guī)則的重要數(shù)據(jù)結(jié)構(gòu)。

我們先來貼一個(gè)鎖的大概分類的圖

根據(jù)加鎖的范圍，MySQL 里面的鎖大致可以分為全局鎖、表鎖、行鎖。我們主要先來學(xué)習(xí)這幾種鎖，這篇我們學(xué)習(xí)全局鎖。

全局鎖

全局鎖就是對整個(gè)數(shù)據(jù)庫加鎖。當(dāng)我們對數(shù)據(jù)庫加了讀鎖之后，其他任何的請求都不能對數(shù)據(jù)庫加寫鎖了，當(dāng)我們對數(shù)據(jù)庫加了寫鎖之后，后續(xù)其他任何的請求都不能對數(shù)據(jù)庫加讀鎖和寫鎖了。

FTWRL

MySQL 提供了一個(gè)加全局讀鎖的方法，F(xiàn)lush tables with read lock (FTWRL)。當(dāng)我們需要讓整個(gè)庫處于只讀狀態(tài)時(shí)，可以使用這個(gè)命令，之后其他線程的以下語句會被阻塞：數(shù)據(jù)更新語句（增刪改）、數(shù)據(jù)定義語句（包括建表、修改表結(jié)構(gòu)等）和更新類事務(wù)的提交語句。

全局鎖的使用場景

全局鎖的使用場景：做全庫的邏輯備份。邏輯備份也就是把整個(gè)庫的每個(gè)表都 select 出來存成文本。也就是全局鎖只有在進(jìn)行主從備份數(shù)據(jù)或者導(dǎo)入導(dǎo)出數(shù)據(jù)的時(shí)候才會使用到。

那么為什么需要全局鎖呢？

因?yàn)槲覀冊谧鰯?shù)據(jù)備份或者導(dǎo)入導(dǎo)出數(shù)據(jù)的時(shí)候，如果在這個(gè)期間還可以同時(shí)進(jìn)行數(shù)據(jù)的增刪改，那么就會出現(xiàn)數(shù)據(jù)不一致的問題。

以前有一種做法是通過上面提到的 FTWRL 確保在備份的時(shí)候不會有其他線程對數(shù)據(jù)庫做更新，注意：這里備份過程中整個(gè)庫都是完全處于只讀狀態(tài)。

因?yàn)槿宙i是面向這個(gè)數(shù)據(jù)庫的，所以加全局鎖聽起來很危險(xiǎn)：

• 如果我們在主庫上備份，在備份期間都不能執(zhí)行更新，也就是基本上全部業(yè)務(wù)暫停。
• 如果我們在從庫上備份，在備份期間主庫同步過來的 binlog 從庫都不能執(zhí)行，也就是會導(dǎo)致主從延遲，數(shù)據(jù)不一致。

如何避免加鎖

既然加全局鎖影響這么大，我們能不能避免加鎖呢？

通過上面的介紹，我們知道加鎖是為了解決數(shù)據(jù)不一致問題。那么是不是只要我們能解決數(shù)據(jù)不一致的問題，就可以不用加全局鎖了。有這樣一個(gè)思路：如果我們在開始進(jìn)行數(shù)據(jù)備份的時(shí)候，記錄一個(gè)操作日志，備份過程中不加鎖允許對數(shù)據(jù)庫的增刪改查，而在備份過程中，增刪改查的操作記錄都記到一個(gè)日志文件里，等我們備份完成后，再把這段時(shí)間日志文件里的操作都執(zhí)行一遍。這樣就能保證備份前后數(shù)據(jù)的一致性了。

總結(jié)，不加鎖的話，備份得到數(shù)據(jù)和主數(shù)據(jù)不是一個(gè)邏輯時(shí)間點(diǎn)，這個(gè)視圖是邏輯不一致的。如果保證邏輯時(shí)間點(diǎn)一致即邏輯視圖一致就能保證數(shù)據(jù)一致，由此我們就想到了我們之前學(xué)過的事務(wù)隔離級別，可重復(fù)復(fù)讀的隔離級別下開啟一個(gè)事務(wù)就是一個(gè)一致性視圖。

在 MySQL 的默認(rèn)引擎 InnoDB 里有一個(gè)機(jī)制可以保證數(shù)據(jù)一致性。InnoDB 引擎中有數(shù)據(jù)快照版本的功能，這個(gè)功能叫 MVCC，因?yàn)?MVCC 保留了歷史版本的快照，每個(gè)快照都對應(yīng)一個(gè)事務(wù)版本號，而在我們備份數(shù)據(jù)的時(shí)候會申請一個(gè)事務(wù)版本號，在讀取數(shù)據(jù)的時(shí)候，只需要讀取比自己事務(wù)版本號小的數(shù)據(jù)即可。

–single-transaction 命令加鎖

官方自帶的邏輯備份工具是 mysqldump。當(dāng) mysqldump 使用參數(shù) –single-transaction 的時(shí)候，導(dǎo)數(shù)據(jù)之前就會啟動(dòng)一個(gè)事務(wù)，來確保拿到一致性視圖。而由于 MVCC 的支持，這個(gè)過程中數(shù)據(jù)是可以正常更新的。

–single-transaction 參數(shù)的作用，設(shè)置事務(wù)的隔離級別為可重復(fù)讀，即 REPEATABLE READ，這樣能保證在一個(gè)事務(wù)中所有相同的查詢讀取到同樣的數(shù)據(jù)，也就大概保證了在 dump 期間，如果其他 InnoDB 引擎的線程修改了表的數(shù)據(jù)并提交，對該 dump 線程的數(shù)據(jù)并無影響。

并且設(shè)置 WITH CONSISTENT SNAPSHOT 為快照級別。設(shè)想一下，如果只是可重復(fù)讀，那么在事務(wù)開始時(shí)還沒 dump 數(shù)據(jù)時(shí)，這時(shí)其他線程修改并提交了數(shù)據(jù)，那么這時(shí)第一次查詢得到的結(jié)果是其他線程提交后的結(jié)果，而 WITH CONSISTENT SNAPSHOT 能夠保證在事務(wù)開啟的時(shí)候，第一次查詢的結(jié)果就是事務(wù)開始時(shí)的數(shù)據(jù) A，即使這時(shí)其他線程將其數(shù)據(jù)修改為 B，查的結(jié)果依然是 A。

single-transaction方法只適用于所有的表使用事務(wù)引擎的庫。在 mysqldump 過程中，加了–single-transaction 就能保證 InnoDB 的數(shù)據(jù)是完全一致的，對于MyISAM這種不支持事務(wù)的引擎，如果備份過程中有更新，總是只能取到最新的數(shù)據(jù)，那么就破壞了備份的一致性。這時(shí)候就還是需要全局鎖的，所以我們就還是需要使用 FTWRL 命令的。

只讀設(shè)置

我們可能還會有這樣一個(gè)疑問，既然要全庫只讀，我們?yōu)槭裁床贿m用 set global readonly = true 的方式呢？

確實(shí) readonly 方式也可以讓全庫進(jìn)入只讀狀態(tài)，但還是會建議用 FTWRL 方式，主要有兩個(gè)原因：

• 在有些系統(tǒng)，readonly 的值會被用來做其他邏輯，比如用來判斷一個(gè)庫是主庫還是備庫。因此，修改global變量的方式影響面更大。
• 在異常處理機(jī)制上有差異。如果執(zhí)行 FTWRL 命令之后由于客戶端發(fā)生異常斷開，那么 MySQL 會自動(dòng)釋放這個(gè)全局鎖，整個(gè)庫回到可以正常更新的狀態(tài)。

而將整個(gè)庫設(shè)置為 readonly 之后，如果客戶端發(fā)生異常，則數(shù)據(jù)庫就會一直保持 readonly 狀態(tài)，這樣會導(dǎo)致整個(gè)庫長時(shí)間處于不可寫狀態(tài)，風(fēng)險(xiǎn)較高。

推薦學(xué)習(xí)：mysql視頻教程