1. 程式人生 > >Mysql中的三類鎖,你知道嗎?

Mysql中的三類鎖,你知道嗎?

導讀

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

  • 今天來細說一下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,表示開啟這個邏輯,預設開啟。 主動死鎖檢測在發生死鎖的時候,是能夠快速發現並進行處理的,但是它也是有額外負擔的。 當併發很高的時候,檢測死鎖將會消耗大量的資源,因此控制併發也是很重要的一種策