MySQL全局鎖指的是什么

這篇文章主要介紹“MySQL全局鎖指的是什么”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“MySQL全局鎖指的是什么”文章能幫助大家解決問題。

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

我們先來貼一個鎖的大概分類的圖

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

全局鎖

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

FTWRL

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

全局鎖的使用場景

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

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

因為我們在做數(shù)據(jù)備份或者導入導出數(shù)據(jù)的時候，如果在這個期間還可以同時進行數(shù)據(jù)的增刪改，那么就會出現(xiàn)數(shù)據(jù)不一致的問題。

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

因為全局鎖是面向這個數(shù)據(jù)庫的，所以加全局鎖聽起來很危險：

• 如果我們在主庫上備份，在備份期間都不能執(zhí)行更新，也就是基本上全部業(yè)務暫停。

• 如果我們在從庫上備份，在備份期間主庫同步過來的 binlog 從庫都不能執(zhí)行，也就是會導致主從延遲，數(shù)據(jù)不一致。

如何避免加鎖

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

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

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

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

–single-transaction 命令加鎖

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

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

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

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

只讀設置

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

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

• 在有些系統(tǒng)，readonly 的值會被用來做其他邏輯，比如用來判斷一個庫是主庫還是備庫。因此，修改global變量的方式影響面更大。

• 在異常處理機制上有差異。如果執(zhí)行 FTWRL 命令之后由于客戶端發(fā)生異常斷開，那么 MySQL 會自動釋放這個全局鎖，整個庫回到可以正常更新的狀態(tài)。

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

關于“MySQL全局鎖指的是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識，可以關注億速云行業(yè)資訊頻道，小編每天都會為大家更新不同的知識點。