數(shù)據(jù)庫之鎖模塊

2024-09-07 22:12:48

字體：大中小

供稿：網(wǎng)友

　　MyISAM與InnoDB關(guān)于鎖方面的區(qū)別:

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

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

　　MyISAM適合的場景：

　　頻繁執(zhí)行全表count語句
　　對數(shù)據(jù)進行增刪改的頻率不高，而查詢非常頻繁的場景
　　沒有事務(wù)場景
　　InnoDB適合的場景：

　　數(shù)據(jù)進行增刪改查都相當(dāng)頻繁的系統(tǒng)
　　可靠性要求比較高，需要事務(wù)特性的系統(tǒng)
　　數(shù)據(jù)庫鎖的分類：

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

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

　　事務(wù)隔離級別以及各級別下的并發(fā)訪問問題以及事務(wù)隔離機制
　　事務(wù)并發(fā)訪問引起的問題以及如何避免：

　　1.更新丟失：

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

　　2.臟讀（Dirty read）：

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

　　3.不可重復(fù)讀（Non-repeatable read）：

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

　　4.幻讀（Phantom read）：

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

　　總結(jié)：

　　當(dāng)前讀和快照讀
　　表象：快照讀（非阻塞讀）-- 偽MVCC（多版本并發(fā)控制）
　　內(nèi)在：next-key鎖（行級鎖+gap鎖）

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

　　select ... lock in share mode；select ... for update
　　update，delete，insert（自動加鎖）
　　之所以叫當(dāng)前讀，是因為讀取的是當(dāng)前記錄的最新版本，而RR事務(wù)隔離級別下在讀取數(shù)據(jù)之后還需要保證其他事務(wù)不能修改當(dāng)前記錄，那么就會對讀取的記錄加next-key鎖，所以RR事務(wù)隔離級別下的當(dāng)前讀可以避免發(fā)生幻讀現(xiàn)象：

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

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

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

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

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

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

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

　　總結(jié)：

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

（編輯：武林網(wǎng)）

上一篇：SQL簡單利用

下一篇：Mycat分表分庫原則