目錄
１. 概述
1.1 定義
在數據庫中，除了傳統的計算資源（如CPU、RAM、I/O等）的爭用以外，數據也是一種供需要用戶共享的資源。如何保證數據併發訪問的一致性、有效性是所有數據庫必須解決的一個問題，鎖衝突也是影響數據庫併發訪問性能的一個重要因素。從這個角度來說，鎖對數據庫而言顯得尤其重要，也更加複雜。
1.2 鎖的分類
讀鎖(共享鎖): 針對同一份數據，多個讀操作可以同時進行而不會互相影響
寫鎖(排它鎖): 當前寫操作沒有完成前，它會阻斷其他寫鎖和讀鎖
2. 鎖
2.1 表鎖（偏向讀操作）
表鎖偏向MyISAM存儲引擎，開銷小，加鎖快，無思索，鎖定粒度大，發生鎖衝突的概率最高，併發度最低。
2.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`test`.`mylock` (`id`, `NAME`) VALUES ('1', 'a');
INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('2', 'b');
INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('3', 'c');
INSERT INTO`test`.`mylock` (`id`, `NAME`) VALUES ('4', 'd');
2.1.2 案例分析(加讀鎖）
當前session和其他session都可以讀該表
當前session中插入或者更新鎖定的表都會報錯，其他session插入或更新則會等待
2.1.3 案例分析(加寫鎖）
mysql> lock table mylock write;
當前session對該表的增刪改查都沒有問題，其他session對該表的所有操作被阻塞
2.1.4 案例結論
MyISAM在執行查詢語句(SELECT)前,會自動給涉及的所有表加讀鎖,在執行增刪改操作前,會自動給涉及的表加寫鎖。
1. 對MyISAM表的讀操作(加讀鎖) ,不會阻寒其他進程對同一表的讀請求,但會阻賽對同一表的寫請求。只有當讀鎖釋放後,纔會執行其它進程的寫操作。
2. 對MylSAM表的寫操作(加寫鎖) ,會阻塞其他進程對同一表的讀和寫操作,只有當寫鎖釋放後,纔會執行其它進程的讀寫操作
簡而言之，就是讀鎖會阻塞寫，但是不會阻塞讀。而寫鎖則會把讀和寫都阻塞。
2.2 行鎖（偏向寫操作）
行鎖偏向InnoDB存儲引擎，開銷大，加鎖慢，會出現死鎖，鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高。InnoDB與MYISAM的最大不同有兩點：一是支持事務（TRANSACTION）；二是採用了行級鎖。
2.2.1 行鎖支持事務
原子性(Atomicity) : 事務是一個原子操作單元,其對數據的修改,要麼全都執行,要麼全都不執行。
一致性(Consistent) : 在事務開始和完成時,數據都必須保持一致狀態。這意味着所有相關的數據規則都必須應用於事務的修改,以保持數據的完整性;事務結束時,所有的內部數據結構(如B樹索引或雙向鏈表)也都必須是正確的。
隔離性(Isolation) : 數據庫系統提供一定的隔離機制,保證事務在不受外部併發操作影響的“獨立”環境執行。這意味着事務處理過程中的中間狀態對外部是不可見的,反之亦然。
持久性(Durable) : 事務完成之後,它對於數據的修改是永久性的,即使出現系統故障也能夠保持。
(2) 併發事務處理帶來的問題
更新丟失(Lost Update) : 當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，由於每個事務都不知道其他事務的存在，就會發生丟失更新問題–最後的更新覆蓋了由其他事務所做的更新。
髒讀(Dirty Reads): 一個事務正在對一條記錄做修改，在這個事務完成並提交前，這條記錄的數據就處於不一致的狀態；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“髒”數據，並據此作進一步的處理，就會產生未提交的數據依賴關係。這種現象被形象的叫做“髒讀”。總結：事務A讀取到了事務B已經修改但尚未提交的數據，還在這個數據基礎上做了操作。此時，如果B事務回滾，A讀取的數據無效，不符合一致性要求。
不可重讀(Non-Repeatable Reads): 一個事務在讀取某些數據後的某個時間，再次讀取以前讀過的數據，卻發現其讀出的數據已經發生了改變、或某些記錄已經被刪除了！這種現象就叫做“不可重複讀”。總結：事務A讀取到了事務B已經提交的修改數據，不符合隔離性
幻讀(Phantom Reads): 一個事務按相同的查詢條件重新讀取以前檢索過的數據，卻發現其他事務插入了滿足其查詢條件的新數據，這種現象就稱爲“幻讀”。總結: 事務A讀取到了事務B提交的新增數據，不符合隔離性
髒讀是事務B裏面修改了數據
(3) 事務隔離級別
髒讀”、“不可重複讀”和“幻讀”,其實都是數據庫讀一致性問題,必須由數據庫提供一定的事務隔離機制來解決。
數據庫的事務隔離越嚴格,併發副作用越小,但付出的代價也就越大,因爲事務隔離實質上就是使事務在一定程度上“串行化”進行,這顯然與“併發”是矛盾的。
同時,不同的應用對讀一致性和事務隔離程度的要求也是不同的,比如許多應用對“不可重複讀"和“幻讀”並不敏感,可能更關心數據併發訪問的能力。
常看當前數據庫的事務隔離級別: show variables like 'tx_isolation';
設置事務隔離級別：set tx_isolation='REPEATABLE-READ';
2.2.2 行鎖案例分析
開啓事務，Session_1更新某一行，Session_2更新同一行被阻塞，但是更新其他行正常; 如果Session_1更新的是一個範圍內的數據, 那麼Session_2更新或新增屬於該範圍的數據行都將會被阻塞, 也就是間隙鎖
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 `test`.`account` (`name`, `balance`) VALUES ('lilei', '450');
INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('hanmei', '16000');
INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('lucy', '2400');
2.3.1 讀未提交
(1) 打開一個客戶端A，並設置當前事務模式爲read uncommitted（未提交讀），查詢表account的初始值
(2) 在客戶端A的事務提交之前，打開另一個客戶端B，更新表account
(3) 這時，雖然客戶端B的事務還沒提交，但是客戶端A就可以查詢到B已經更新的數據
(4) 一旦客戶端B的事務因爲某種原因回滾，所有的操作都將會被撤銷，那客戶端A查詢到的數據其實就是髒數據
(5) 在客戶端A執行更新語句update account set balance = balance - 50 where id =1，lilei的balance沒有變成350，居然是400，是不是很奇怪，數據不一致啊，如果你這麼想就太天真 了，在應用程序中，我們會用400-50=350，並不知道其他會話回滾了，要想解決這個問題可以採用讀已提交的隔離級別
2.3.2 讀已提交
(1) 打開一個客戶端A，並設置當前事務模式爲read committed（未提交讀），查詢表account的所有記錄
(2) 在客戶端A的事務提交之前，打開另一個客戶端B，更新表account
(3) 這時，客戶端B的事務還沒提交，客戶端A不能查詢到B已經更新的數據，解決了髒讀問題
(5) 客戶端A執行與上一步相同的查詢，結果 與上一步不一致，即產生了不可重複讀的問題
(1) 打開一個客戶端A，並設置當前事務模式爲repeatable read，查詢表account的所有記錄
(2) 在客戶端A的事務提交之前，打開另一個客戶端B，更新表account並提交
(3) 在客戶端A查詢表account的所有記錄，與步驟(1)查詢結果一致，沒有出現不可重複讀的問題
(4) 在客戶端A，接着執行update balance = balance - 50 where id = 1，balance沒有變成400-50=350，lilei的balance值用的是步驟（2）中的350來算的，所以是300，數據的一致性倒是沒有被破壞。可重複讀的隔離級別下使用了MVCC機制，select操作不會更新版本號，是快照讀（歷史版本）；insert、update和delete會更新版本號，是當前讀（當前版本）
(6) 在客戶端A查詢表account的所有記錄，沒有 查出 新增數據，所以沒有出現幻讀
(7) 驗證幻讀, 在客戶端A執行update account set balance=888 where id = 4;能更新成功，再次查詢能查到客戶端B新增的數據
2.3.4 串行化
(1) 打開一個客戶端A，並設置當前事務模式爲serializable，查詢表account的初始值：
mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from account;
+------+--------+---------+
| id | name | balance |
+------+--------+---------+
| 1 | lilei | 10000 |
| 2 | hanmei | 10000 |
| 3 | lucy | 10000 |
| 4 | lily | 10000 |
+------+--------+---------+
4 rows in set (0.00 sec)
(2) 打開一個客戶端B，並設置當前事務模式爲serializable，插入一條記錄報錯，表被鎖了插入失敗，mysql中事務隔離級別爲serializable時會鎖表，因此不會出現幻讀的情況，這種隔離級別併發性極低，開發中很少會用到。
mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into account values(5,'tom',0);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
問題: Mysql默認級別是repeatable-read，有辦法解決幻讀問題嗎？
解答: 間隙鎖在某些情況下可以解決幻讀問題; 要避免幻讀可以用間隙鎖在Session_1下面執行update account set name = 'zhuge' where id > 10 and id <=20;，則其他Session沒法插入這個範圍內的數據
2.4 案例結論
Innodb存儲引擎由於實現了行級鎖定，雖然在鎖定機制的實現方面所帶來的性能損耗可能比表級鎖定會要更高一下，但是在整體併發處理能力方面要遠遠優於MYISAM的表級鎖定的。當系統併發量高的時候，Innodb的整體性能和MYISAM相比就會有比較明顯的優勢了。
但是，Innodb的行級鎖定同樣也有其脆弱的一面，當我們使用不當的時候，可能會讓Innodb的整體性能表現不僅不能比MYISAM高，甚至可能會更差。
2.5 行鎖分析
通過檢查InnoDB_row_lock狀態變量來分析系統上的行鎖的爭奪情況
show status like'innodb_row_lock%';
對各個狀態量的說明如下：
Innodb_row_lock_current_waits: 當前正在等待鎖定的數量
Innodb_row_lock_time: 從系統啓動到現在鎖定總時間長度
Innodb_row_lock_time_avg: 每次等待所花平均時間
尤其是當等待次數很高，而且每次等待時長也不小的時候，我們就需要分析系統中爲什麼會有如此多的等待，然後根據分析結果着手製定優化計劃。
2.6 死鎖
set tx_isolation='repeatable-read';
Session_1執行：select * from account where id=1 for update;
Session_2執行：select * from account where id=2 for update;
Session_1執行：select * from account where id=2 for update;
Session_2執行：select * from account where id=1 for update;
查看近期死鎖日誌信息：show engine innodb status\G;
大多數情況mysql可以自動檢測死鎖並回滾產生死鎖的那個事務，但是有些情況mysql沒法自動檢測死鎖