本篇文章給大家帶來了關于mysql的相關知識，其中主要介紹了關于全局鎖的相關問題，全局鎖就是對整個數據庫加鎖。當我們對數據庫加了讀鎖之后，其他任何的請求都不能對數據庫加寫鎖了，下面一起來看一下，希望對大家有幫助。

推薦學習：mysql視頻教程

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

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

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

全局鎖

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

FTWRL

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

全局鎖的使用場景

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

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

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

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

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

• 如果我們在主庫上備份，在備份期間都不能執行更新，也就是基本上全部業務暫停。
• 如果我們在從庫上備份，在備份期間主庫同步過來的 binlog 從庫都不能執行，也就是會導致主從延遲，數據不一致。

如何避免加鎖

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

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

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

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

–single-transaction 命令加鎖

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

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

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

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

只讀設置

我們可能還會有這樣一個疑問，既然要全庫只讀，我們為什么不適用 set global readonly = true 的方式呢？

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

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

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

推薦學習：mysql視頻教程