MySQL的鎖一般分為三種
- 行鎖
- 表鎖
- 頁鎖
表鎖
偏向MyISAM儲存引擎，開銷小，加鎖快；無死鎖；鎖定粒度大，發生鎖沖突的概率最高，并發度最低
MyISAM在執行查詢語句（SELECT）前，會自動給涉及的所有表加讀鎖，在執行增刪改操作前，會自動給設計的表加寫鎖。
對MyISAM表的讀操作（加讀鎖），不會阻塞其他進程對同一表的寫請求，只有當讀鎖釋放后，才會執行其他進程的寫操作
舉例說明
首先創建一個MyISAM引擎的表
create table mylock(
id int not null primary key auto_increment，
name varchar(255)
)engine MyISAM;
session1加讀鎖
lock table mylock read;
session1可以查看（SELECT），session2也可以查看
session1不可以查看其他表，不可以更改該鎖表
session2可以查看鎖表和其他表，更改鎖表時會阻塞，session1解鎖后執行
session2修改鎖表
update mylock set name='a3' where id = 1;/*會阻塞*/
session1解鎖，session2修改語句執行
unlock tables;
對MyISAM表的寫操作（加寫鎖），會阻塞其他進程對同一表的讀和寫操作，只有寫鎖釋放后，才會執行其他進程的讀寫操作
session1加寫鎖
lock table mylock write;
session1不能查看其他表
session2查看鎖表會阻塞，等session1解鎖后執行
簡而言之，就是讀鎖會阻塞寫，但是不會阻塞讀，而寫鎖會把讀和寫都阻塞
查看哪些表被加鎖
show open tables;
也可以通過下面命令，檢查Table_locks_waited和Table_locks_immediate狀態量來分析系統上的表鎖定
show status like 'table%';
Table_locks_waited:出現表級鎖定爭用而發生等待的次數（不能立即獲取鎖的次數，每等待一次鎖值加1），此值高則說明存在較高的表級鎖爭用情況
Table_locks_immediate:產生表級鎖定的次數，表示可以立即獲取鎖的查詢次數，魅力及獲取鎖值加1
此外，MyISAM的讀寫鎖調度是寫優先，這也是MyISAM不適合做寫為主表的引擎，因為寫鎖以后，其他線程不能做任何操作，大量的更新會使查詢難得到鎖，從而造成永遠阻塞
行鎖
偏向InnoDB儲存引擎，開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，并發度最高
InnoDB與MyISAM的最大不同有兩點
- 支持事務（TRANSCTION）
- 采用行級鎖
并發事務帶來的問題
- 更新丟失（A，B同時修改，其中一人的被覆蓋）
- 臟讀（B讀到A修改但未提交的數據，若A事務回滾，則B讀到的數據無效）
- 不可重復讀（事務A讀到事務B已經提交的數據）
- 幻讀（B讀到A新增但未提交的數據，若A事務回滾，則B讀到的數據無效）
隔離級別
“臟讀”，“不可重復讀”和“幻讀”，其實都是數據庫讀一致性問題，必須由數據庫提供一定的事務隔離機制來解決
| 隔離級別 | 讀數據一致性 | 臟讀 | 不可重復讀 | 幻讀 |
| ------------- |:-------------| -----|
| 未提交讀（Read Uncommitted） | 最低級別，只能保證不讀取物理上損壞的數據 | 是 | 是 | 是 |
| 已提交讀（Read Committed） | 語句級 | 否 | 是 | 是 |
| 可重復讀（Repeatable read） | 事務級 | 否 | 否 | 是 |
| 可序列化（Serializable） | 最高級別，事務級 | 否 | 否 | 否 |
數據庫的事務隔離越嚴格，并發的副作用越小，但付出的代價就越大，因為事務實質上就是事務在一定程度上“串行化”進行，這杏眼與“并發”是矛盾的，同事，不同的應用對讀一致性和事務隔離程度的要求也是不同的，比如許多應用對“不可重復讀”和“幻讀”并不敏感，可能更關心數據訪問的能力。
查看隔離級別
show variables like 'tx_ioslation';
舉例說明
首先創建一個InnoDB引擎的表
create table linelock(
id int（11），
name varchar(255)
)engine InnoDB;
創建索引，根據索引鎖定行
create index id_ind on linelock(id);
create index name_ind on linelock(name);
session1和session2把自動提交關閉
set autocommit = 0;
雙方commit之前，session只能讀自己所更改的，若autocommit=1則可立即讀到其他session commit的數據
若同時修改同一行的數據，后修改的會被阻塞，等前者coommit后才執行，后者也要commit使改變生效，后者會覆蓋前者
索引失效導致行鎖變成表鎖
session1執行索引失效的語句
update linelcok set id = 10 where name= jack;/*varchar沒加單引號使索引失效，行鎖變表鎖*/
session2執行其他行的更新語句會被阻塞，session1 commit之后執行
update linelcok set id = 9 where name= 'mike';/*會阻塞*/
間隙鎖產生危害
當我們用范圍條件而不是相等條件檢索數據，并請求共享或排他鎖時，InnoDB會給符合條件的已有數據記錄的索引加鎖；對于鍵值在條件范圍內但并不存在的記錄叫做“間隙（GAP）”
InnoDB會對這個“間隙”加鎖，這種鎖的機制就是所謂的間隙鎖（Next-Key Lock）
間隙鎖會使不存在的鍵值被無辜地鎖定，而造成在鎖定時無法插入鎖定鍵值范圍內的任何數據。在某些場景下可能會對性能造成很大的危害
舉例說明
| id | name |
|---|---|
| 1 | jack |
| 3 | mike |
| 4 | john |
linelock表中數據
| id | name |
|---|---|
| 1 | jack |
| 3 | mike |
| 4 | john |
session1執行范圍更新
update linelock set name ='may' where id>1 and id <5;
session2執行間隙更新，要session1 commit之后才會執行
update linelock set name ='amy' where id=2;/*會阻塞*/
查看行鎖狀態
show status like 'innodb_row_lock%';
各狀態量說明如下：
Innodb_row_lock_current_waits:當前正在等待鎖定的數量；
Innodb_row_lock_time:從系統啟動到現在鎖定總時間長度；
Innodb_row_lock_time_avg:每次等待所花的平均時間；
Innodb_row_lock_time_max:從系統啟動到現在等待最長的一次所花的時間；
Innodb_row_lock_waits:系統啟動后到現在總共等待的次數；
當等待次數很高，而且每次等待時長也不小的時候，我們需要分析系統為何有如此多的等待，然后制定優化計劃。
優化建議
- 盡可能讓所有數據檢索都通過索引來完成，避免無索引行鎖升級為表鎖
- 合理設計索引，盡量縮小鎖的范圍
- 盡可能較少檢索條件，避免間隙鎖
- 盡量控制事務大小，較少鎖定資源量和時間長度
- 盡可能低級別事務隔離
頁鎖
開銷和加鎖時間界于表鎖和行鎖之間；會出現死鎖；鎖定粒度界于表鎖和行鎖之間，并發度一般。
