面試題1：先說一下什么是MySQL事務(wù)吧

正經(jīng)回答：

簡單說，事務(wù)就是一組原子性的SQL執(zhí)行單元。如果數(shù)據(jù)庫引擎能夠成功地對數(shù)據(jù)庫應(yīng) 用該組査詢的全部語句，那么就執(zhí)行該組SQL。如果其中有任何一條語句因為崩潰或其 他原因無法執(zhí)行，那么所有的語句都不會執(zhí)行。要么全部執(zhí)行成功（commit），要么全部執(zhí)行失?。╮ollback）。

這里引用銀行轉(zhuǎn)賬的例子，假設(shè)銀行的數(shù)據(jù)庫有兩張表：信用卡(credit)表和儲蓄(savings)表。用戶陳哈哈要把信用卡里最后100塊錢額度轉(zhuǎn)到他 的儲蓄賬戶用來吃飯，那么需要至少三個步驟：

• 檢査信用卡余額是否髙于100塊錢。
• 從信用卡賬戶余額中減去100塊錢。
• 在儲蓄賬戶余額中增加100塊錢。

上述三個步驟必須在同一個事務(wù)中執(zhí)行，任何一個SQL失敗，則必須回滾所有的SQL。這里用START TRANSACTION語句開啟事務(wù)，要么使用COMMIT提交事務(wù)將修改的數(shù)據(jù)持久保留，要么使用ROLLBACK銷所有的修改。事務(wù)SQL的樣本如下：

START TRANSACTION;
-- 檢查信用卡賬戶額度
SELECT balance FROM credit WHERE customer_id = 'chenhh';
-- 信用卡表扣錢
UPDATE credit SET balance = balance - 100.00 WHERE customer_id = 'chenhh';
-- 儲蓄表加錢
UPDATE savings SET balance = balance + 100.00 WHERE customer_id = 'chenhh';
COMMIT;

試想一下，如果執(zhí)行到第四條語句時服務(wù)器崩潰了，會發(fā)生什么？廢話，我被坑了100塊錢，中午只能餓肚子！再假如，在執(zhí)行到第三條語句和第四 條語句之間時，同一時間，另外一個進程，來自商場結(jié)賬的女朋友，也要信用卡賬戶的100塊，那么結(jié)果可能就是銀行在不知道這個邏輯的情況下白白給了陳哈哈女朋友100塊錢？

深入追問： 追問1：說一下你對ACID四大特性的理解

該問題來自“MySQL江湖路”專欄中的博文：《數(shù)據(jù)庫ACID四大特性到底為了啥，一文帶你看通透》

ACID特性：原子性、一致性、隔離性、持久性

原子性(Atomicity)

單個事務(wù)，為一個不可分割的最小工作單元，整個事務(wù)中的所有操作要么全部commit成功，要么全部失敗rollback，對于一個事務(wù)來說，不可能只執(zhí)行其中的一部分SQL操作，這就是事務(wù)的原子性。

一致性(Consistency)

數(shù)據(jù)庫總是從一個一致性的狀態(tài)轉(zhuǎn)換到另外一個一致性的狀態(tài)。在前面的例子中， 一致性確保了，即使在執(zhí)行第三、四條語句之間時系統(tǒng)崩潰，信用卡賬戶也不會損 失100塊，因為事務(wù)最終沒有提交，所以事務(wù)中所做的修改也不會保存到數(shù)據(jù)庫中，保證數(shù)據(jù)一致性。

隔離性(Isolation)

通常來說，一個事務(wù)所做的修改在最終提交以前，對其他事務(wù)是不可見的。在前面 的例子中，當(dāng)執(zhí)行完第三條語句、第四條語句還未開始時，此時有另外一個賬戶查詢余額SQL開始運行，則其看到的信用卡賬戶的余額并沒有被減去100元。后面我們討論隔離級別(Isolation level)的時候，會發(fā)現(xiàn)為什么我們要說事務(wù)通常來說是不可見的。

持久性(Durability)

一旦事務(wù)提交，則其所做的修改就會永久保存到數(shù)據(jù)庫中。此時即使系統(tǒng)崩潰，修改的數(shù)據(jù)也不會丟失。

事務(wù)的ACID特性可以確保銀行不會弄丟你的錢。而在應(yīng)用邏輯中，要實現(xiàn)這一點非常難, 甚至可以說是不可能完成的任務(wù)。一個兼容ACID的數(shù)據(jù)庫系統(tǒng)，需要做很多復(fù)雜但可能用戶并沒有覺察到的工作，才能確保ACID的實現(xiàn)。

追問2：可以從原理上聊一下ACID具體是怎么實現(xiàn)的么？

對MySQL來說，邏輯備份日志（binlog）、重做日志（redolog）、回滾日志（undolog）、鎖技術(shù) + MVCC就是MySQL實現(xiàn)事務(wù)的基礎(chǔ)。

• 原子性：通過undolog來實現(xiàn)。
• 持久性：通過binlog、redolog來實現(xiàn)。
• 隔離性：通過(讀寫鎖+MVCC)來實現(xiàn)。
• 一致性：MySQL通過原子性，持久性，隔離性最終實現(xiàn)（或者說定義）數(shù)據(jù)一致性。

1、原子性原理

事務(wù)通常是以BEGIN TRANSACTION 開始，以 COMMIT 或 ROLLBACK 結(jié)束。

• COMMIT 表示提交，即提交事務(wù)的所有操作并持久化到數(shù)據(jù)庫中。
• ROLLBACK表示回滾，即在事務(wù)中運行的過程中發(fā)生了某種故障，事務(wù)不能繼續(xù)執(zhí)行，系統(tǒng)將事務(wù)中對數(shù)據(jù)庫所有已完成的操作全部撤銷，回滾到事務(wù)開始時的狀態(tài)，這里的操作指對數(shù)據(jù)庫的更新操作，已執(zhí)行的查詢操作不用管。這時候也就需要用到 undolog 來進行回滾。

undolog：

• 每條數(shù)據(jù)變更（INSERT/UPDATE/DELETE/REPLACE）等操作都會生成一條undolog記錄，在SQL執(zhí)行前先于數(shù)據(jù)持久化到磁盤。
• 當(dāng)事務(wù)需要回滾時，MySQL會根據(jù)回滾日志對事務(wù)中已執(zhí)行的SQL做逆向操作，比如 DELETE 掉一行數(shù)據(jù)的逆向操作就是再把這行數(shù)據(jù) INSERT回去，其他操作同理。

2、持久性原理

先了解一下MySQL的數(shù)據(jù)存儲機制，MySQL的表數(shù)據(jù)是存放在磁盤上的，因此想要存取的時候都要經(jīng)歷磁盤 IO,然而即使是使用 SSD 磁盤 IO 也是非常消耗性能的。為此，為了提升性能 InnoDB 提供了緩沖池(Buffer Pool)，Buffer Pool 中包含了磁盤數(shù)據(jù)頁的映射，可以當(dāng)做緩存來使用：

• 讀數(shù)據(jù)：會首先從緩沖池中讀取，如果緩沖池中沒有，則從磁盤讀取在放入緩沖池；
• 寫數(shù)據(jù)：會首先寫入緩沖池，緩沖池中的數(shù)據(jù)會定期同步到磁盤中；

我們知道，MySQL表數(shù)據(jù)是持久化到磁盤中的，但如果所有操作都去操作磁盤，等并發(fā)上來了，那處理速度誰都吃不消，因此引入了緩沖池(Buffer Pool)的概念，Buffer Pool 中包含了磁盤中部分數(shù)據(jù)頁的映射，可以當(dāng)做緩存來用；這樣當(dāng)修改表數(shù)據(jù)時，我們把操作記錄先寫到Buffer Pool中，并標(biāo)記事務(wù)已完成，等MySQL空閑時，再把更新操作持久化到磁盤里（你可能會問，到底什么時候執(zhí)行持久化呢？1、MySQL線程低于高水位；2、當(dāng)有其他查詢、更新語句操作該數(shù)據(jù)頁時），從而大大緩解了MySQL并發(fā)壓力。

但是它也帶來了新的問題，當(dāng)MySQL系統(tǒng)宕機，斷電時Buffer Pool數(shù)據(jù)不就丟了？

因為我們的數(shù)據(jù)已經(jīng)提交了，但此時是在緩沖池里頭，還沒來得及在磁盤持久化，所以我們急需一種機制需要存一下已提交事務(wù)的數(shù)據(jù)，為恢復(fù)數(shù)據(jù)使用。

于是 redo log + binlog的經(jīng)典組合就登場了，這里不在擴展贅述。

3、隔離性原理

隔離性是事務(wù)ACID特性里最復(fù)雜的一個。在SQL標(biāo)準(zhǔn)里定義了四種隔離級別，每一種級別都規(guī)定一個事務(wù)中的修改，哪些是事務(wù)之間可見的，哪些是不可見的。

級別越低的隔離級別可以執(zhí)行越高的并發(fā)，但同時實現(xiàn)復(fù)雜度以及開銷也越大。

Mysql 隔離級別有以下四種（級別由低到高）：

搞懂了隔離級別以及實現(xiàn)原理其實就可以理解ACID里的隔離性了。前面說過原子性，隔離性，持久性的目的都是為了要做到一致性，但隔離型跟其他兩個有所區(qū)別，原子性和持久性是為了要實現(xiàn)數(shù)據(jù)的正確、可用，比如要做到宕機后的恢復(fù)、事務(wù)的回滾等，保證數(shù)據(jù)是正確可用的！

那么隔離性是要做到什么呢？

隔離性要管理的是：多個并發(fā)讀寫請求（事務(wù)）過來時的執(zhí)行順序。像交警在馬路口兒指揮交通一樣，當(dāng)并發(fā)處理多個DML更新操作時，如何讓事務(wù)操作他該看到的數(shù)據(jù)，出現(xiàn)多個事務(wù)處理同一條數(shù)據(jù)時，讓事務(wù)該排隊的排隊，別插隊搗亂，保證數(shù)據(jù)和事務(wù)的相對隔離，這就是隔離性要干的事兒。

所以，從隔離性的實現(xiàn)原理上，我們可以看出這是一場數(shù)據(jù)的可靠性與性能之間的權(quán)衡。

4、一致性原理

一致性，我們要保障的是數(shù)據(jù)一致性，數(shù)據(jù)庫中的增刪改操作，使數(shù)據(jù)庫不斷從一個一致性的狀態(tài)轉(zhuǎn)移到另一個一致性的狀態(tài)。

事務(wù)該回滾的回滾，該提交的提交，提交后該持久化磁盤的持久化磁盤，該寫緩沖池的寫緩沖池+寫日志；對于數(shù)據(jù)可見性，通過四種隔離級別進行控制，使得庫表中的有效數(shù)據(jù)范圍可控，保證業(yè)務(wù)數(shù)據(jù)的正確性的前提下，進而提高并發(fā)程度，支撐服務(wù)高QPS的穩(wěn)定運行，保證數(shù)據(jù)的一致性，這就是咱們叨叨叨說的清楚想不明白的數(shù)據(jù)庫ACID四大特性。

面試題2：并發(fā)場景下事務(wù)會存在哪些數(shù)據(jù)問題？ 正經(jīng)回答：

并發(fā)場景下MySQL事務(wù)可能會出現(xiàn)臟讀、幻讀、不可重復(fù)讀問題；

臟讀(Drity Read)：某個事務(wù)已更新一份數(shù)據(jù)，另一個事務(wù)在此時讀取了同一份數(shù)據(jù)，由于某些原因，前一個RollBack了操作，則后一個事務(wù)所讀取的數(shù)據(jù)就會是不正確的。

不可重復(fù)讀(Non-repeatable read):在一個事務(wù)的兩次查詢之中數(shù)據(jù)不一致，這可能是兩次查詢過程中間插入了一個事務(wù)更新了原有的數(shù)據(jù)。

幻讀(Phantom Read):在一個事務(wù)的兩次查詢中數(shù)據(jù)筆數(shù)不一致，例如有一個事務(wù)查詢了幾列(Row)數(shù)據(jù)，而另一個事務(wù)卻在此時插入了新的幾列數(shù)據(jù)，先前的事務(wù)在接下來的查詢中，就會發(fā)現(xiàn)有幾列數(shù)據(jù)是它先前所沒有的。

深入追問：

追問1：那Innodb是如何解決幻讀問題的呢？

先說結(jié)論，MySQL 存儲引擎 InnoDB 在可重復(fù)讀（RR）隔離級別下是解決了幻讀問題的。

方法是通過next-key lock在當(dāng)前讀事務(wù)開啟時，1.給涉及到的行加寫鎖（行鎖）防止寫操作；2.給涉及到的行兩端加間隙鎖(Gap Lock)防止新增行寫入；從而解決了幻讀問題。

幻讀出現(xiàn)的場景： 1.幻讀出現(xiàn)在可重復(fù)讀（RR）隔離級別下，普通的SELECT查詢就是快照讀，是不會看到別的事務(wù)插入的數(shù)據(jù)的。因此，幻讀在“當(dāng)前讀”下才會出現(xiàn)。（當(dāng)前讀會生成行鎖，但行鎖只能鎖定存在的行，針對新插入的操作沒有限定）

2.上面 session B 的修改結(jié)果，被 session A 之后的 select 語句用“當(dāng)前讀”看到，不能稱為幻讀。幻讀僅專指“新插入的行”。

3.因為這三個查詢都是加了 for update，都是當(dāng)前讀。而當(dāng)前讀的規(guī)則，就是要能讀到所有已經(jīng)提交的記錄的最新值。并且，session B 和 sessionC 的兩條語句，執(zhí)行后就會提交，所以 Q2 和 Q3 就是應(yīng)該看到這兩個事務(wù)的操作效果，而且也看到了，這跟事務(wù)的可見性規(guī)則并不矛盾。

幻讀場景實例：

測試表數(shù)據(jù)如下：

mysql> select * from LOL; +----+--------------+--------------+-------+ | id | hero_title | hero_name | price | +----+--------------+--------------+-------+ | 1 | 刀鋒之影 | 泰隆 | 6300 | | 2 | 迅捷斥候 | 提莫 | 6300 | | 3 | 光輝女郎 | 拉克絲 | 1350 | | 4 | 發(fā)條魔靈 | 奧莉安娜 | 6300 | | 5 | 至高之拳 | 李青 | 6300 | | 6 | 無極劍圣 | 易 | 450 | | 7 | 疾風(fēng)劍豪 | 亞索 | 6300 | +----+--------------+--------------+-------+ 7 rows in set (0.00 sec)

下面是一個出現(xiàn)幻讀情況的示例流程：

可以看到，session A 里執(zhí)行了三次查詢，分別是 Q1、Q2 和 Q3。它們的 SQL 語句相同，都是 select * from LOL where price=450 for update。這個語句的意思你應(yīng)該很清楚了，查所有 price=450 的行，而且使用的是當(dāng)前讀，并且加上寫鎖?，F(xiàn)在，我們來看一下這三條 SQL 語句，分別會返回什么結(jié)果。

1.Q1 只返回 “無極劍圣” 這一行；

2.在 T2 時刻，session B 把 “疾風(fēng)劍豪” 這一行的 price 值改成了 450，因此 T3 時刻 Q2 查出來的是 “無極劍圣” 和 “疾風(fēng)劍豪” 這兩行；

3.在 T4 時刻，session C 又插入一行 (10,‘雪人騎士',‘努努',‘450')，因此 T5 時刻 Q3 查出來 price = 450 的是"無極劍圣" 、“疾風(fēng)劍豪” 和 “雪人騎士” 這三行。

其中，Q3 讀到 (10,‘雪人騎士',450) 這一行的現(xiàn)象，被稱為“幻讀”。也就是說，幻讀指的是一個事務(wù)在前后兩次查詢同一個范圍的時候，后一次查詢看到了前一次查詢沒有看到的行。

一、原理解讀

那么幻讀能僅通過行鎖解決么？答案是否定的，如上面示例，首先說明一下，select xx for update（當(dāng)前讀）是將所有條件涉及到的（符合where條件）行加上行鎖。但是，就算我在select xx for update 事務(wù)開啟時將所有的行都加上行鎖。那么也鎖不住Session C新增的行，因為在我給數(shù)據(jù)加鎖的時刻，壓根就還沒有新增的那行，自然也不會給新增行加上鎖。

所以要解決幻讀，就必須得解決新增行的問題。

現(xiàn)在你應(yīng)該明白了，產(chǎn)生幻讀的原因是：行鎖只能鎖住行，但是新插入記錄這個動作，要更新的是記錄之間的“間隙”。因此，為了解決幻讀問題，InnoDB 只好引入新的鎖，也就是間隙鎖 (Gap Lock)。顧名思義，間隙鎖，鎖的就是兩個值之間的空隙。比如文章開頭的表 LOL，初始化插入了 7 個記錄，這就產(chǎn)生了 8 個間隙。

二、next-key lock

這樣，當(dāng)你執(zhí)行 select * from LOL where hero_title = ‘疾風(fēng)劍豪' for update 的時候，就不止是給數(shù)據(jù)庫中已有的 7 個記錄加上了行鎖，還同時加了 8 個間隙鎖。這樣就確保了無法再插入新的記錄，也就是Session C在T4新增(10,‘雪人騎士',‘努努',‘450') 行時，由于ID大于7，被間隙鎖（7，+∞）鎖住。

在一行行掃描的過程中，不僅將給行加上了行鎖，還給行兩邊的空隙，也加上了間隙鎖。MySQL將行鎖 + 間隙鎖組合統(tǒng)稱為 next-key lock，通過 next-key lock 解決了幻讀問題。

注意：

next-key lock的確是解決了幻讀問題，但是next-key lock在并發(fā)情況下也經(jīng)常會造成死鎖。死鎖檢測和處理也會花費時間，一定程度上影響到并發(fā)量。

面試題3：說一下MySQL中你都知道哪些鎖？

正經(jīng)回答：

1.按鎖粒度從大到小分類：表鎖，頁鎖和行鎖；以及特殊場景下使用的全局鎖

2.如果按鎖級別分類則有：共享（讀）鎖、排他（寫）鎖、意向共享（讀）鎖、意向排他（寫）鎖；

3.以及Innodb引擎為解決幻讀等并發(fā)場景下事務(wù)存在的數(shù)據(jù)問題，引入的Record Lock（行記錄鎖）、Gap Lock（間隙鎖）、Next-key Lock（Record Lock + Gap Lock結(jié)合）等；

4.還有就是我們面向編程的兩種鎖思想：悲觀鎖、樂觀鎖。

深入追問： 追問1：那你來談一談你對表鎖、行鎖的理解吧。

表鎖

表級別的鎖定是MySQL各存儲引擎中最大顆粒度的鎖定機制。該鎖定機制最大的特點是實現(xiàn)邏輯非常簡單，帶來的系統(tǒng)負面影響最小。所以獲取鎖和釋放鎖的速度很快。由于表級鎖一次會將整個表鎖定，所以可以很好的避免困擾我們的死鎖問題。

當(dāng)然，鎖定顆粒度大所帶來最大的負面影響就是出現(xiàn)鎖定資源爭用的概率也會最高，大大降低并發(fā)度。

使用表級鎖定的主要是MyISAM，MEMORY，CSV等一些非事務(wù)性存儲引擎。

行鎖

與表鎖正相反，行鎖最大的特點就是鎖定對象的顆粒度很小，也是目前各大數(shù)據(jù)庫管理軟件所實現(xiàn)的鎖定顆粒度最小的。由于鎖定顆粒度很小，所以發(fā)生鎖定資源爭用的概率也最小，能夠給予應(yīng)用程序盡可能大的并發(fā)處理能力從而提高系統(tǒng)的整體性能。

雖然能夠在并發(fā)處理能力上面有較大的優(yōu)勢，但是行級鎖定也因此帶來了不少弊端。由于鎖定資源的顆粒度很小，所以每次獲取鎖和釋放鎖需要做的事情也更多，帶來的消耗自然也就更大了。此外，行級鎖定也最容易發(fā)生死鎖。

使用行級鎖定的主要是InnoDB存儲引擎。

• 適用場景：從鎖的角度來說，表級鎖更適合于以查詢?yōu)橹?，只有少量按索引條件更新數(shù)據(jù)的應(yīng)用，如Web應(yīng)用；而行級鎖則更適合于有大量按索引條件并發(fā)更新數(shù)據(jù)的情況，同時又有并發(fā)查詢的應(yīng)用場景。

頁鎖

除了表鎖、行鎖外，MySQL還有一種相對偏中性的頁級鎖，頁鎖是MySQL中比較獨特的一種鎖定級別，在其他數(shù)據(jù)庫管理軟件中也并不是太常見。頁級鎖定的特點是鎖定顆粒度介于行級鎖定與表級鎖之間，所以獲取鎖定所需要的資源開銷，以及所能提供的并發(fā)處理能力也同樣是介于上面二者之間。另外，頁級鎖定和行級鎖定一樣，會發(fā)生死鎖。

使用頁級鎖定的主要是BerkeleyDB存儲引擎。

追問2：那全局鎖是什么時候用的呢？

首先全局鎖，是對整個數(shù)據(jù)庫實例加鎖。使用場景一般在全庫邏輯備份時。

MySQL提供加全局讀鎖的命令：Flush tables with read lock (FTWRL)

這個命令可以使整個庫處于只讀狀態(tài)。使用該命令之后，數(shù)據(jù)更新語句、數(shù)據(jù)定義語句和更新類事務(wù)的提交語句等修改數(shù)據(jù)庫的操作都會被阻塞。

風(fēng)險：

1.如果在主庫備份，在備份期間不能更新，業(yè)務(wù)停擺

2.如果在從庫備份，備份期間不能執(zhí)行主庫同步的binlog，導(dǎo)致主從延遲同步

還有一種鎖全局的方式：set global readonly=true ，相當(dāng)于將整個庫設(shè)置成只讀狀態(tài)，但這種修改global配置量級較重，和全局鎖不同的是：如果執(zhí)行Flush tables with read lock 命令后，如果客戶端發(fā)生異常斷開，那么MySQL會自動釋放這個全局鎖，整個庫回到可以正常更新的狀態(tài)。但將庫設(shè)置為readonly后，客戶端發(fā)生異常斷開，數(shù)據(jù)庫依舊會保持readonly狀態(tài)，會導(dǎo)致整個庫長時間處于不可寫狀態(tài)，試想一下微信只能看，不能打字~~

追問2：那你再說一下按鎖級別劃分的那幾種鎖的使用場景和理解吧？

MySQL基于鎖級別又分為：共享（讀）鎖、排他（寫）鎖、意向共享（讀）鎖、意向排他（寫）鎖

對于共享（讀）鎖、排他（寫）鎖，比如咱們住酒店，入住前顧客都是有權(quán)看房的，只看不住想白嫖都是可以的，前臺小姐姐會把門給你打開。當(dāng)然，也允許不同的顧客一起看（共享 讀），

看房時房間相當(dāng)于公共場所，小姐姐囑咐不能亂涂亂畫，也不能偷喝免費的礦泉水。。如果你覺得不錯，偷偷跑到前臺要定這間房，交錢后會給你這個房間的鑰匙并將房間狀態(tài)改為已入住，不再允許其他人看房（排他 寫）。

對了，當(dāng)辦理入住時前臺小姐姐也會通知看房的殺馬特小伙子說這間房已經(jīng)有人定了??！等看房的殺馬特小伙兒罵罵咧咧出門后，看到滿頭大汗的你，鄙夷著咽了一口口水，咳tui！然后你鎖上門哼著歌兒，開始干那些見不得人的事兒~~直到你退房前，其他人無法在看你的房。

可見，讀鎖是可以并發(fā)獲取的（共享的），而寫鎖只能給一個事務(wù)處理（排他的）。當(dāng)你想獲取寫鎖時，需要等待之前的讀鎖都釋放后方可加寫鎖；而當(dāng)你想獲取讀鎖時，只要數(shù)據(jù)沒有被寫鎖鎖住，你都可以獲取到讀鎖，然后去看房。

另外還有意向讀\寫鎖，嚴格來說他們并不是一種鎖，而是存放表中所有行鎖的信息。就像我們在酒店，當(dāng)我們預(yù)定一個房間時，就對該行（房間）添加 意向?qū)戞i，但是同時會在酒店的前臺對該行（房間）做一個信息登記（旅客姓名、男女、住多長時間、家里幾頭牛等）。大家可以把意向鎖當(dāng)成這個酒店前臺，它并不是真正意義上的鎖（鑰匙），它維護表中每行的加鎖信息，是共用的。后續(xù)的旅客通過酒店前臺來看哪個房間是可選的，那么，如果沒有意圖鎖，會出現(xiàn)什么情況呢？假設(shè)我要住房間，那么我每次都要到每一個房間看看這個房間有沒有住人，顯然這樣做的效率是很低下的。殺馬特小伙兒表示支持！

讀寫鎖、意向鎖的兼容性如下所示；

我們再回到MySQL原理上講

1、共享（讀）鎖（Share Lock）

共享鎖，又叫讀鎖，是讀取操作（SELECT）時創(chuàng)建的鎖。其他用戶可以并發(fā)讀取數(shù)據(jù)，但在讀鎖未釋放前，也就是查詢事務(wù)結(jié)束前，任何事務(wù)都不能對數(shù)據(jù)進行修改（獲取數(shù)據(jù)上的寫鎖），直到已釋放所有讀鎖。

如果事務(wù)A對數(shù)據(jù)B（1024房）加上讀鎖后，則其他事務(wù)只能對數(shù)據(jù)B上加讀鎖，不能加寫鎖。獲得讀鎖的事務(wù)只能讀數(shù)據(jù)，不能修改數(shù)據(jù)。

SQL顯示加鎖寫法:

SELECT … LOCK IN SHARE MODE;

在查詢語句后面增加LOCK IN SHARE MODE，MySQL就會對查詢結(jié)果中的每行都加讀鎖，當(dāng)沒有其他線程對查詢結(jié)果集中的任何一行使用寫鎖時，可以成功申請讀鎖，否則會被阻塞。其他線程也可以讀取使用了讀鎖的表，而且這些線程讀取的是同一個版本的數(shù)據(jù)。

2、排他（寫）鎖（Exclusive Lock）

排他鎖又稱寫鎖、獨占鎖，如果事務(wù)A對數(shù)據(jù)B加上寫鎖后，則其他事務(wù)不能再對數(shù)據(jù)B加任何類型的鎖。獲得寫鎖的事務(wù)既能讀數(shù)據(jù)，又能修改數(shù)據(jù)。

SQL顯示加鎖寫法:

SELECT … FOR UPDATE;

在查詢語句后面增加FOR UPDATE，MySQL 就會對查詢結(jié)果中的每行都加寫鎖，當(dāng)沒有其他線程對查詢結(jié)果集中的任何一行使用寫鎖時，可以成功申請寫鎖，否則會被阻塞。另外成功申請寫鎖后，也要先等待該事務(wù)前的讀鎖釋放才能操作。

3、意向鎖（Intention Lock）

意向鎖屬于表級鎖，其設(shè)計目的主要是為了在一個事務(wù)中揭示下一行將要被請求鎖的類型。InnoDB 中的兩個表鎖：

• 意向共享鎖（IS）：表示事務(wù)準(zhǔn)備給數(shù)據(jù)行加入共享鎖，也就是說一個數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖；
• 意向排他鎖（IX）：類似上面，表示事務(wù)準(zhǔn)備給數(shù)據(jù)行加入排他鎖，說明事務(wù)在一個數(shù)據(jù)行加排他鎖前必須先取得該表的IX鎖。

意向鎖是 InnoDB 自動加的，不需要用戶干預(yù)。

再強調(diào)一下，對于INSERT、UPDATE和DELETE，InnoDB 會自動給涉及的數(shù)據(jù)加排他鎖；對于一般的SELECT語句，InnoDB 不會加任何鎖，事務(wù)可以通過以下語句顯式加共享鎖或排他鎖。

共享鎖：SELECT … LOCK IN SHARE MODE; 排他鎖：SELECT … FOR UPDATE;

總結(jié)

本篇文章就到這里了，希望能給你帶來幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容!

最新評論