數據庫之鎖模塊

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鎖來避免幻讀。