數據庫之鎖模塊

MyISAM與InnoDB關于鎖方面的區別

MyISAM與InnoDB關于鎖方面的區別：

• MyISAM默認使用的是表級鎖，不支持行級鎖
• InnoDB默認用的是行級鎖，也支持表級鎖
• InnoDB支持事務，在事務中被加鎖的數據行需要 等事務commit之后才會統一解鎖，否則不會解鎖。而MyISAM不支持事務，所以不會有這個問題
• MyISAM和InnoDB都支持共享鎖和排他鎖，讀鎖共享，寫鎖排他
• InnoDB在開啟事務時，若select語句不走索引的情況會鎖住整張表，也就是說InnoDB在SQL沒有利用到索引的時候使用的是表級鎖，而SQL用到索引的時候則是使用行級鎖和gap鎖，gap鎖是走普通非唯一索引時用到的
• InnoDB除了支持行級鎖之外，還支持表級的意向鎖，意向鎖分為共享讀鎖（IS）和排他寫鎖（IX）

注：

實際上在不走索引的時候，InnoDB的實現方式和MyIsam的表鎖方式不同，單條索引記錄上加鎖，record lock鎖住的永遠是索引，而非記錄本身，即使該表上沒有任何索引，那么innodb會在后臺創建一個隱藏的聚集主鍵索引，那么鎖住的就是這個隱藏的聚集主鍵索引。所以說當一條sql沒有走任何索引時，那么將會在每一條聚集索引后面加X鎖（排他鎖），此時想改變樹型結構即索引結構的話，是會被鎖住的，這個類似于表鎖，但原理上和表鎖是完全不同的

MyISAM適合的場景：

• 頻繁執行全表count語句
• 對數據進行增刪改的頻率不高，而查詢非常頻繁的場景
• 沒有事務場景

InnoDB適合的場景：

• 數據進行增刪改查都相當頻繁的系統
• 可靠性要求比較高，需要事務特性的系統

數據庫鎖的分類：

• 按鎖的粒度劃分，可分為表級鎖、行級鎖、頁級鎖
• 按鎖級別劃分，可分為共享鎖、排他鎖
• 按加鎖方式劃分，可分為自動鎖、顯式鎖
• 按操作劃分，可分為DML鎖、DDL鎖
• 按使用方式劃分，可分為樂觀鎖、悲觀鎖；悲觀鎖通常需要利用數據庫提供的鎖機制來實現；而樂觀鎖通常用版本號或時間戳來實現

總結：

MyISAM默認使用的是表級鎖，不支持行級鎖。InnoDB默認用的是行級鎖，也支持表級鎖。無論是表級鎖還是行級鎖，均分為共享鎖和排他鎖，它們的關系如下表所示（X：排他鎖，S：共享鎖）：

事務隔離級別以及各級別下的并發訪問問題以及事務隔離機制

事務并發訪問引起的問題以及如何避免：

1.更新丟失：

即一個事務的更新覆蓋了另一個事務的更新；由于現在主流數據庫都會自動加鎖來避免更新丟失的情況，所以在數據庫層面通常不會發生這個問題。例如mysql所有事務隔離級別在數據庫層面上均可避免更新丟失

下圖模擬了更新丟失的過程：

2.臟讀（Dirty read）：

即一個事務讀到另一個事務的未提交數據；該問題在READ-COMMITTED（讀已提交）以上的事務隔離級別可避免

3.不可重復讀（Non-repeatable read）：

即事務A多次讀取同一數據，但事務B在事務A多次讀取的過程中對該數據做了更新操作并提交，導致事務A多次讀取同一數據時結果不一致；該問題在REPEATABLE-READ（可重復讀）以上的事務隔離級別可避免，這也是MySQL的默認隔離級別

4.幻讀（Phantom read）：

事務A讀取以搜索條件相匹配的若干行數據，而事務B則對事務A查詢匹配的數據進行了插入或刪除操作，導致事務A多次讀取的結果集行數不一致；該問題在SERIALIZABLE（串行化）以上的事務隔離級別可避免，需要注意的是：在MySQL數據庫中，REPEATABLE-READ事務隔離級別下也可以避免幻讀

總結：

當前讀和快照讀

表象：快照讀（非阻塞讀）-- 偽MVCC（多版本并發控制）
內在：next-key鎖（行級鎖+gap鎖）

首先我們需要知道兩個概念：當前讀和快照讀；當前讀其實就是加了鎖的增刪改查語句，例：

• select ... lock in share mode；select ... for update
• update，delete，insert（自動加鎖）

之所以叫當前讀，是因為讀取的是當前記錄的最新版本，而RR事務隔離級別下在讀取數據之后還需要保證其他事務不能修改當前記錄，那么就會對讀取的記錄加next-key鎖，所以RR事務隔離級別下的當前讀可以避免發生幻讀現象：

快照讀則是不加鎖的非阻塞讀，例如不加鎖的普通select操作。但需要注意的是在串行化的事務隔離級別下，任何的增刪改查操作都會被加鎖。

在mysql中，讀已提交隔離級別下，快照讀和當前讀都是讀到同樣的數據。而在可重復讀隔離級別下，快照讀讀到的是開啟事務時第一條select語句讀到的快照版本數據，當前讀則是會讀到當前數據庫中最新的數據。

RC、RR級別下的InnoDB的快照讀（非阻塞讀）是如何實現的：

• 一是依靠數據行里的隱藏字段：DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID字段
  • DB_TRX_ID：最后修改本行數據的事務id
  • DB_ROLL_PTR：回滾指針，指向undo日志的歷史版本數據
  • DB_ROW_ID：行號，即密集索引維護的自增id
• 二是undo日志，當我們對數據進行變更操作時就會產生undo日志，undo日志中存儲的是歷史數據，當一個舊事務需要讀取數據時，會順著undo鏈找到滿足其可見性的數據；undo日志還分為insert undo日志和update undo日志
  • insert undo日志：記錄insert操作產生的undo日志，該日志記錄只在事務回滾時需要，而在事務提交后會立即丟棄
  • update undo日志：記錄update或delete操作產生的undo日志，該日志記錄不僅在事務回滾時需要，快照讀也需要，所以不會馬上被刪除，只有當數據庫所使用的快照中不涉及該日志記錄才會被刪除
• 三是read view，它主要用來做可見性判斷的，即當我們去執行快照讀時，會針對我們查詢的數據創建一個read view，以此來決定該事務能看到的是哪個版本的數據。read view的創建時機是開啟事務后執行的第一條select語句
  • read view遵循一個可見性算法，該算法會先取出將要變更數據行的DB_TRX_ID，與系統其他活躍的事務id做對比，如果大于等于這些活躍的事務id就會通過DB_ROLL_PTR去undo日志里取出DB_TRX_ID小于當前活躍事務id的歷史數據

事務對行的更新過程：

RR事務隔離級別下是如何避免幻讀的

在之前的小節中，我們了解到在MySQL的RR事務隔離級別下，是可以避免幻讀的。但并不意味著快照讀是避免發生幻讀現象的根本，因為快照讀只是讀的發生變化前的歷史數據。實際在RR及SERIALIZABLE事務隔離級別下真正防止幻讀發生的原因是事務對數據加上了next-key鎖，而next-key鎖由行鎖和gap鎖兩部分組成。行鎖就不多說了，gap鎖才是重點，所謂gap就是索引樹中插入新記錄的間隙，而gap鎖是用于鎖定一個間隙范圍但不包括記錄本身，gap鎖的目的是為了防止同一事務的兩次當前讀而導致出現幻讀的情況。

gap鎖只在RR和SERIALIZABLE事務隔離級別中存在，其他的隔離級別是沒有的，所以RC和RU是無法避免幻讀的。這里我們主要討論RR事務隔離級別下gap鎖出現的場景：

• 增刪改查及當前讀若用到主鍵索引或唯一索引會對其加gap鎖嗎？
  • 答：視情況而定，如果where條件全部命中，則不會用gap鎖，只會加行鎖；而where條件部分命中或者全不命中，則會加gap鎖；所以gap鎖會用在非唯一索引或者不走索引的當前讀中

where條件全部命中，只會加行鎖：

走非唯一索引時會對該索引間隙加gap鎖：

不走索引則會對表里所有的間隙加gap鎖，其效果就類似于表級鎖了，但是其代價比表級鎖更大：

總結：

無論是當前讀還是快照讀，在innodb的RR的事務隔離級別下都可以避免幻讀。在快照讀的情況下，innodb通過mvcc來避免幻讀；在當前讀的情況下，innodb通過next-key鎖來避免幻讀。