一、概述

1.1 定義

• 鎖是計算機協調多個程序或執行緒併發訪問某一資源的機制
• 計算資源（如CPU、RAM、I/O等）的爭用以外，資料也是一種供需要使用者共享的資源。如何保證資料併發訪問的一致性、有效性是所有資料庫必須解決的一個問題，鎖衝突也是影響資料庫併發訪問效能的一個重要因素。從這個角度來說，鎖對資料庫而言顯得尤其重要，也更加複雜

1.2 鎖的分類

• 從效能上分為樂觀鎖（用版本對比來實現）和悲觀鎖
• 從對資料庫操作的型別分，分為讀鎖和寫鎖(都屬於悲觀鎖)
  • 讀鎖（共享鎖）：針對同一份資料，多個讀操作可以同時進行而不會互相影響
  • 寫鎖（排它鎖）：當前寫操作沒有完成前，它會阻斷其他寫鎖和讀鎖
• 從對資料操作的粒度分，分為表鎖和行鎖

二、表鎖、行鎖

1、表鎖（偏讀）

表鎖偏向MyISAM儲存引擎，開銷小，加鎖快，無思索，鎖定粒度大，發生鎖衝突的概率最高，併發度最低。

1.1、基本操作

• 建表

CREATE TABLE `mylock` (
`id` INT (11) NOT NULL AUTO_INCREMENT,
`name` VARCHAR (20) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE = MyISAM DEFAULT CHARSET = utf8;
INSERT INTO `mylock` (`id`, `name`) VALUES ('1', 'a');
INSERT
 
 INTO `mylock` (`id`, `name`) VALUES ('2', 'b');
INSERT INTO `mylock` (`id`, `name`) VALUES ('3', 'c');
INSERT INTO `mylock` (`id`, `name`) VALUES ('4', 'd');

• 手動新增表鎖

lock table 表名稱 read/write

• 查看錶上加過的鎖

show open tables;

• 刪除表鎖

unlock tables;

1.2、案例分析加（讀鎖）

• 當前session和其他session都可以讀該表
• 當前session中插入或者更新鎖定的表都會報錯，其他session插入或更新則會等待

1.3、案例分析加（寫鎖）

• 當前session對該表的增刪改查都沒有問題，其他session對該表的所有操作被阻塞

1.4、案例結論

• MyISAM在執行查詢語句(SELECT)前,會自動給涉及的所有表加讀鎖,在執行增刪改操作前,會自動給涉及的表加寫鎖。
• 對MyISAM表的讀操作(加讀鎖) ,不會阻寒其他程序對同一表的讀請求,但會阻賽對同一表的寫請求。只有當讀鎖釋放後,才會執行其它程序的寫操作。
• 對MylSAM表的寫操作(加寫鎖) ,會阻塞其他程序對同一表的讀和寫操作,只有當寫鎖釋放後,才會執行其它程序的讀寫操作
• 簡而言之，就是讀鎖會阻塞寫，但是不會阻塞讀。而寫鎖則會把讀和寫都阻塞

2、行鎖（偏寫）

表中沒有索引時，innodb將對整個表加鎖，而不能體現行鎖的特性

• 行鎖偏向InnoDB儲存引擎，開銷大，加鎖慢，會出現死鎖，鎖定粒度最小
• 發生鎖衝突的概率最低，併發度也最高。InnoDB與MYISAM的最大不同有兩點：一是支援事務（TRANSACTION）；二是採用了行級鎖

2.1、事務

2.1.1、事務（Transaction）及其ACID屬性

事務是由一組SQL語句組成的邏輯處理單元,事務具有以下4個屬性,通常簡稱為事務的ACID屬性

• 原子性(Atomicity) ：事務是一個原子操作單元,其對資料的修改,要麼全都執行,要麼全都不執行
• 一致性(Consistent) ：在事務開始和完成時,資料都必須保持一致狀態。這意味著所有相關的資料規則都必須應用於事務的修改,以保持資料的完整性;事務結束時,所有的內部資料結構(如B樹索引或雙向連結串列)也都必須是正確的
• 隔離性(Isolation)：資料庫系統提供一定的隔離機制,保證事務在不受外部併發操作影響的“獨立”環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的,反之亦然
• 永續性(Durable) ：事務完成之後,它對於資料的修改是永久性的,即使出現系統故障也能夠保持

2.1.2 併發事務處理帶來的問題

更新丟失（Lost Update） 當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，由於每個事務都不知道其他事務的存在，就會發生丟失更新問題–最後的更新覆蓋了由其他事務所做的更新

髒讀（Dirty Reads） 一個事務正在對一條記錄做修改，在這個事務完成並提交前，這條記錄的資料就處於不一致的狀態；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“髒”資料，並據此作進一步的處理，就會產生未提交的資料依賴關係。這種現象被形象的叫做“髒讀”。 　　一句話：事務A讀取到了事務B已經修改但尚未提交的資料，還在這個資料基礎上做了操作。此時，如果B事務回滾，A讀取的資料無效，不符合一致性要求 　　 不可重讀（Non-Repeatable Reads） 一個事務在讀取某些資料後的某個時間，再次讀取以前讀過的資料，卻發現其讀出的資料已經發生了改變、或某些記錄已經被刪除了！這種現象就叫做“不可重複讀”。 　　一句話：事務A讀取到了事務B已經提交的修改資料，不符合隔離性

幻讀（Phantom Reads） 一個事務按相同的查詢條件重新讀取以前檢索過的資料，卻發現其他事務插入了滿足其查詢條件的新資料，這種現象就稱為“幻讀”。 　　一句話：事務A讀取到了事務B提交的新增資料，不符合隔離性

髒讀是事務B裡面修改了資料 幻讀是事務B裡面新增了資料

2.1.3、事務隔離級別

髒讀”、“不可重複讀”和“幻讀”,其實都是資料庫讀一致性問題,必須由資料庫提供一定的事務隔離機制來解決

資料庫的事務隔離越嚴格,併發副作用越小,但付出的代價也就越大,因為事務隔離實質上就是使事務在一定程度上“序列化”進行,這顯然與“併發”是矛盾的。

同時,不同的應用對讀一致性和事務隔離程度的要求也是不同的,比如許多應用對“不可重複讀"和“幻讀”並不敏感,可能更關心資料併發訪問的能力。

檢視當前資料庫的事務隔離級別:

show variables like 'tx_isolation';

設定事務隔離級別:

set tx_isolation='REPEATABLE-READ';

2.2、行鎖案例分析

需要開啟事務，Session_1更新某一行，Session_2更新同一行被阻塞，但是更新其他行正常

2.3、MySQL中select * for update鎖表的問題

由於InnoDB預設是Row-Level Lock，所以只有「明確」的指定主鍵，MySQL才會執行Row lock (只鎖住被選取的資料例) ，否則MySQL將會執行Table Lock (將整個表單給鎖住)。

舉個例子: 假設有個表單products ，裡面有id跟name二個欄位，id是主鍵。 例1: (明確指定主鍵，並且有此筆資料，row lock)

SELECT * FROM products WHERE id=’3’ FOR UPDATE; 
SELECT * FROM products WHERE id=’3’ and type=1 FOR UPDATE;

例2: (明確指定主鍵，若查無此筆資料，無lock)

SELECT * FROM products WHERE id=’-1’ FOR UPDATE;

例2: (無主鍵，table lock)

SELECT * FROM products WHERE name=’Mouse’ FOR UPDATE;

例3: (主鍵不明確，table lock)

SELECT * FROM products WHERE id<>’3’ FOR UPDATE;

例4: (主鍵不明確，table lock)

SELECT * FROM products WHERE id LIKE ‘3’ FOR UPDATE;

注: FOR UPDATE僅適用於InnoDB，且必須在開啟事務(BEGIN/COMMIT)中才能測試。

2.3、 隔離級別案例分析

CREATE TABLE `account` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `balance` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `account` (`name`, `balance`) VALUES ('lilei', '450');
INSERT INTO `account` (`name`, `balance`) VALUES ('hanmei', '16000');
INSERT INTO `account` (`name`, `balance`) VALUES ('lucy', '2400');

讀未提交、讀已提交 省略。。。

2.4、可重複讀

-- 設定隔離級別 可重複讀
 set tx_isolation='repeatable-read'；

session1 兩次查詢結果一致，沒有出現不可重複讀的問題

在session1中，接著執行update balance = balance - 50 where id = 1，balance沒有變成450-50=400，lilei的balance值用的是步驟（2）中的400來算的，所以是350，資料的一致性倒是沒有被破壞。可重複讀的隔離級別下使用了MVCC機制，select操作不會更新版本號，是快照讀（歷史版本）；insert、update和delete會更新版本號，是當前讀（當前版本）

沒有解決 幻讀

Mysql預設級別是repeatable-read，有辦法解決幻讀問題嗎？

間隙鎖在某些情況下可以解決幻讀問題

要避免幻讀可以用間隙鎖在Session_1下面執行update account set name = ‘zhuge’ where id > 10 and id <=20;，則其他Session沒法插入這個範圍內的資料

2.5、結論

Innodb儲存引擎由於實現了行級鎖定，雖然在鎖定機制的實現方面所帶來的效能損耗可能比表級鎖定會要更高一下，但是在整體併發處理能力方面要遠遠優於MYISAM的表級鎖定的。當系統併發量高的時候，Innodb的整體效能和MYISAM相比就會有比較明顯的優勢了。 　　但是，Innodb的行級鎖定同樣也有其脆弱的一面，當我們使用不當的時候，可能會讓Innodb的整體效能表現不僅不能比MYISAM高，甚至可能會更差。