導讀

• 正所謂有人(鎖)的地方就有江湖(事務)，人在江湖飄，怎能一無所知？

• 今天來細說一下Mysql中的三類鎖，分別是全域性鎖、表級鎖、行級鎖。

• 文章首發於作者公眾號【碼猿技術專欄】，原創不易，喜歡的點個贊關注一下，謝謝！！！

全域性鎖

• 全域性鎖簡單的說就是鎖住整個資料庫例項，命令是Flush tables with read lock。當你需要為整個資料庫處於只讀的狀態的時候，可以使用這個命令。
• 一旦使用全域性鎖，之後其他執行緒的以下語句會被阻塞：資料更新語句（資料的增刪改）、資料定義語句（包括建表、修改表結構等）和更新類事務的提交語句。
• 全域性鎖的使用場景大部分都是用來資料庫備份。

為什麼備份要加全域性鎖？

• 使用者買東西，首先會從餘額里扣除金額，然後在訂單裡新增商品。如果備份資料庫，不加鎖，並且備份順序為先備份用餘額，再備份訂單商品，有可能備份了使用者餘額後，使用者下訂單買東西提交事務，然後再備份訂單商品表， 此時訂單商品已存在。最後備份出來的資料為。最後使用者餘額為買東西前的餘額，沒有減少，但是訂單商品卻多了。演示如下圖：

• 這種情況可能使用者會覺得賺了，但是如果備份順序反過來，先備份商品表再備份餘額表，使用者就會發現我付了錢，但是商品沒有加，這中結果就會更加的嚴重。
• 因此保證備份資料的一致性很重要，必要的手段就是加鎖。

全域性鎖有什麼壞處？

• 全域性鎖是個啥？介紹完了讀者心裡已經有數了，讓這個庫只讀？這是多麼可怕的操作，簡單列舉幾個危險之處：
  • 如果在主庫備份，備份期間不能執行任何更新操作，會導致整個業務停擺，高併發情況下更甚。
  • 如果你在從庫上備份，那麼備份期間從庫不能執行主庫同步過來的binlog，會導致主從延遲。

全域性備份比較好的解決方案

• 全域性鎖遠瞅不錯，近瞅嚇一跳，陳某在此不推薦使用。
• 其實 官方自帶的邏輯備份工具是mysqldump。當mysqldump使用引數**–single-transaction**的時候，導資料之前就會啟動一個事務，來確保拿到一致性檢視。而由於MVCC的支援，這個過程中資料是可以正常更新的。
• 一致性備份是好，但前提是儲存引擎支援事務，這也是MyISAM被InnoDB取代的原因之一。

表級鎖

• MySQL裡面表級別的鎖有兩種：一種是表鎖，一種是元資料鎖（meta data lock，MDL)。
• 表鎖一般是在資料庫引擎不支援行鎖的時候才會被用到的 。
• MDL會直到事務提交才釋放，在做表結構變更的時候，你一定要小心不要導致鎖住線上查詢和更新 。

如何加表鎖

• 顯式加表鎖和解鎖的語句很簡單，如下：

    lock tables tb_name read/write;

    unlock tables;

• 需要注意，lock tables語法除了會限制別的執行緒的讀寫外，也限定了本執行緒接下來的操作物件。
• 舉個例子, 如果在某個執行緒A中執行lock tables t1 read, t2 write; 這個語句，則其他執行緒寫t1、讀寫t2的語句都會被阻塞。同時，執行緒A在執行unlock tables之前，也只能執行讀t1、讀寫t2的操作。連寫t1都不允許，自然也不能訪問其他表。

MDL

• MDL不需要顯式使用，在訪問一個表的時候會被自動加上。
• 當對一個表做增刪改查操作的時候，加MDL讀鎖；當要對錶做結構變更操作的時候，加MDL寫鎖。
• 讀鎖之間不互斥，因此你可以有多個執行緒同時對一張表增刪改查。
• 讀寫鎖之間、寫鎖之間是互斥的，用來保證變更表結構操作的安全性。因此，如果有兩個執行緒要同時給一個表加欄位，其中一個要等另一個執行完才能開始執行。

查詢表級鎖爭用

• 查詢表級鎖的爭用可以通過以下引數分析獲得：
  • Table_locks_immediate：能夠立即獲得表級鎖的次數
  • Table_locks_waited： 不能立即獲取表級鎖而需要等待的次數
• 查詢語句如下：

    show status like 'table_locks_waited'

• 如果Table_locks_waited的值比較大，則說明存在著較嚴重的表級鎖爭用情況。

行級鎖

• MySQL的行鎖是在引擎層由各個引擎自己實現的。但並不是所有的引擎都支援行鎖，比如MyISAM引擎就不支援行鎖。不支援行鎖意味著併發控制只能使用表鎖，對於這種引擎的表，同一張表上任何時刻只能有一個更新在執行，這就會影響到業務併發度。InnoDB是支援行鎖的，這也是MyISAM被InnoDB替代的重要原因之一。
• InnoDB的行鎖是針對索引加的鎖，不是針對記錄加的鎖。並且該索引不能失效，否則都會從行鎖升級為表鎖。
• 在InnoDB事務中，行鎖是在需要的時候才加上的，但並不是不需要了就立刻釋放，而是要等到事務結束時才釋放。
• 行級鎖分為排它鎖（寫鎖）、共享鎖（讀鎖）、間隙鎖。

排他鎖

• 排他鎖，也稱寫鎖，獨佔鎖，當前寫操作沒有完成前，它會阻斷其他寫鎖和讀鎖。
• Mysql中的更新語句(update/delete/insert)會自動加上排它鎖。

• 如上圖，事務B中的update語句被阻塞了，直到事務A提交才能執行更新操作。
• 排他鎖也可以手動新增，如下：

    select * from user where id=1 for update;

• 注意以下兩點：
  • 行鎖是針對索引加鎖的，上述例子中id是主鍵索引。
  • 加了排他鎖並不是其他的事務不能讀取這行的資料，而是不能再在這行上面加鎖了。

間隙鎖

• 當我們用範圍條件檢索資料，並請求共享或排他鎖時，InnoDB會給符合條件的已有資料記錄的索引項加鎖；對於鍵值在條件範圍內但並不存在的記錄，叫做"間隙(GAP)"。InnoDB也會對這個"間隙"加鎖，這種鎖機制就是所謂的間隙鎖(Next-Key鎖)。

• 如上圖，給id>5中並不存在的資料加上了間隙鎖，當插入id=6的資料時被阻塞了。
• 這是一個坑：若執行的條件是範圍過大，則InnoDB會將整個範圍內所有的索引鍵值全部鎖定，很容易對效能造成影響

共享鎖

• 共享鎖，也稱讀鎖，多用於判斷資料是否存在，多個讀操作可以同時進行而不會互相影響。當如果事務對讀鎖進行修改操作，很可能會造成死鎖。如下圖所示。

分析行鎖定

• 通過檢查InnoDB_row_lock 狀態變數分析系統上的行鎖的爭奪情況 。

    show status like 'innodb_row_lock%' 

• innodb_row_lock_current_waits: 當前正在等待鎖定的數量。
• innodb_row_lock_time: 從系統啟動到現在鎖定總時間長度；非常重要的引數
• innodb_row_lock_time_avg: 每次等待所花平均時間；非常重要的引數。
• innodb_row_lock_time_max: 從系統啟動到現在等待最常的一次所花的時間；
• innodb_row_lock_waits: 系統啟動後到現在總共等待的次數；非常重要的引數。直接決定優化的方向和策略。

死鎖解決方案

1、直接進入等待，直到超時。這個超時時間可以通過引數innodb_lock_wait_timeout來設定，預設50秒。注意超時時間不能設定太短，如果僅僅是短暫的等待，一旦設定時間很短，很快便解鎖了，會出現誤傷。

2、發起死鎖檢測，發現死鎖後，主動回滾死鎖鏈條中的某一個事務，讓其他事務得以繼續執行。將引數innodb_deadlock_detect設定為on，表示開啟這個邏輯，預設開啟。 主動死鎖檢測在發生死鎖的時候，是能夠快速發現並進行處理的，但是它也是有額外負擔的。 當併發很高的時候，檢測死鎖將會消耗大量的資源，因此控制併發也是很重要的一種策