6.1 什么是鎖？
6.2 lock 和 latch
展示 lock 信息：
1 show engine innodb status
2 information_schema 表中的
innodb_trx, // ?事務(wù)信息
innodb_locks, // 鎖信息
innodb_lock_waits // 鎖等待
連接三個(gè)表狂巢， 查詢鎖等待信息： 待補(bǔ)
6.3 InnoDB 引擎中的鎖
6.3.1 鎖的類型
共享鎖（S Lock）： 允許事務(wù)讀一行數(shù)據(jù)
排他鎖（X Lock）： 允許事務(wù)刪除或更新一行數(shù)據(jù)
意向鎖的兩種類型 --
意向共享鎖（IS Lock）： 事務(wù)想要獲得一張表中某幾行的共享鎖
意向排他鎖（IX Lock）： 事務(wù)想要獲得一張表中某幾行的排他鎖
6.3.2 一致性非鎖定讀
//演示的例子有問題
指 InnoDB 存儲引擎通過多版本控制(Multi Version Concurrency Control, MVCC)的方式讀取當(dāng)前執(zhí)行時(shí)間數(shù)據(jù)庫中行的數(shù)據(jù)梗搅。//讀取數(shù)據(jù)的快照
之所以稱其為非鎖定讀尸疆， 因?yàn)椴恍枰却L問的行上 X 鎖的釋放。
在 InnoDB 存儲引擎的默認(rèn)設(shè)置下（REPEATABLE READ）， 這是默認(rèn)的讀取方式志衍。
在 READ COMMITTED （總讀快照最新）和 REPEATABLE READ （讀事務(wù)開始時(shí)的）下， InnoDB 引擎使用非鎖定的一致性讀
6.3.3 一致性鎖定讀
在某些情況下聊替， 用戶需要顯示地對數(shù)據(jù)庫讀取操作進(jìn)行加鎖以保證數(shù)據(jù)邏輯的一致性楼肪。這要求數(shù)據(jù)庫支持加鎖語句， 即使是對于 select 的只讀操作惹悄。
select ... for update ?加了 X 鎖春叫， 其他事務(wù)不能對其加任何鎖。
select ... ?lock in share mode 加了 S 鎖泣港，其他事務(wù)只能對其加 S 鎖暂殖， 若加 X 鎖， 則會被阻塞当纱。
以上兩種加鎖模式只能在一個(gè)事務(wù)中呛每， 事務(wù)提交了， 鎖也就被釋放了坡氯。
6.3.4 自增長與鎖
插入操作會依據(jù)自增長計(jì)數(shù)器（auto-increment counter）加 1 賦予自增長列晨横， 這種實(shí)現(xiàn)方式稱作Auto-Inc Locking
這種鎖采用一種特殊的表鎖機(jī)制洋腮， 為了提高插入的性能， 鎖不是在一個(gè)事務(wù)完成后才釋放手形， 而是在完成自增長值插入的 SQL 語句后立即釋放啥供。 // 可以車市下它的鎖等待
innodb_autoinc_lock_mode ,控制自增長的模式， 該參數(shù)默認(rèn)值為 1.
為 1 時(shí)： 對于 “simple inserts”, 該值會用互斥量（mutex）去對內(nèi)存中的計(jì)數(shù)器進(jìn)行累加的操作库糠。對于“bulk inserts” 還是使用傳統(tǒng)表鎖的 auto-inc Locking 范式伙狐。需要注意的是， 如果已經(jīng)使用 auto-inc locing 方式去產(chǎn)生自增長的值瞬欧， 而這時(shí)需要再進(jìn)行“simple inserts”的操作時(shí)鳞骤， 還是需要等待 auto-inc locking 的釋放。
6.3.5 外鍵和鎖（待理解）
在 InnoDB 存儲引擎中黍判， 對于一個(gè)外鍵列豫尽， 如果梅雨顯示地對這個(gè)列加索引， InnoDB 存儲引擎自動對其加一個(gè)索引顷帖， 因?yàn)檫@樣可以避免表鎖美旧。
對于外鍵值的插入或更新， 首先需要查詢父表中的記錄贬墩， 及 select 父表榴嗅。 但對于父表的 select 操作， 不是使用一致性非鎖定讀的方式陶舞， 因?yàn)檫@樣會發(fā)生數(shù)據(jù)不一致的問題嗽测， 因此使用的是 select ... lock in share mode 方式，即主動對父表加一個(gè) S 鎖肿孵，如果這時(shí)父表上已經(jīng)加 X 鎖唠粥， 自表上的操作會被阻塞。
兩個(gè) Session 中停做， 執(zhí)行父表的 x 鎖晤愧，未 commit 或 rollback 時(shí)，另一個(gè) session 的修改操作會被阻塞蛉腌；
6.4 鎖的算法
6.4.1 行鎖的 3 種算法
Record Lock : 單個(gè)行記錄上的鎖
Gap Lock ： 間隙鎖官份， 鎖定一個(gè)范圍， 但不含記錄本身
Next-Key Lock: ?Gap Lock + Record Lock , 鎖定一個(gè)范圍烙丛， 并且鎖定記錄本身
6.4.2 解決 Phantom Problem
兩個(gè)事務(wù)中舅巷，由于一個(gè)事務(wù)的修改操作， 導(dǎo)致另一個(gè)事務(wù)的兩次查詢操作（一般為范圍查詢河咽，如 select * from t where a> 2）钠右， 結(jié)果不唯一。
// 例子沒有操作成功库北， 會話 2 的 插入操作不成功爬舰， 盡管 tx_isolation 已經(jīng)設(shè)置 了 read-commited
如果用戶通過索引查詢一個(gè)值， 并對該行加一個(gè) S Lock寒瓦， 那么即使查詢的值不在情屹， 其鎖定的也是一個(gè)范圍， 因此若沒有返回任何行杂腰， 那么新插入的值一定是唯一的垃你。
6.5 鎖的問題
6.5.1 臟讀
一個(gè)事務(wù)可以讀到另一個(gè)事務(wù)中未提交的數(shù)據(jù)。
臟頁指的是在緩存池中已經(jīng)修改的頁喂很， 但是還沒有刷新到磁盤中惜颇， 即數(shù)據(jù)庫實(shí)例內(nèi)存中的頁和磁盤中的頁的數(shù)據(jù)是不一致的， 當(dāng)然在刷新到磁盤之前少辣， 日志已經(jīng)被寫入到了重做日志文件中凌摄。 臟讀數(shù)據(jù)是指事務(wù)對緩沖池中行記錄的修改， 并且還沒有被提交漓帅。
臟讀發(fā)生條件是需要事務(wù)的隔離級別為 READ UNCOMMITTED, 而目前絕大部分的數(shù)據(jù)庫至少設(shè)置成 READ COMMITTED.
6.5.2 不可重復(fù)讀
不可重復(fù)讀和臟讀的區(qū)別是：臟讀是讀到未提交的數(shù)據(jù)锨亏， 而不可重復(fù)讀讀到的是已經(jīng)提交的數(shù)據(jù)， 但是違反了數(shù)據(jù)庫的事務(wù)一致性要求忙干。
這種問題被定義為 Phantom Problem , 即 幻讀問題器予。
6.5.3 丟失更新
丟失更新時(shí)另一個(gè)鎖導(dǎo)致的問題， 簡單來說就是一個(gè)事務(wù)的更新操作會被另一個(gè)事務(wù)的更新操作鎖覆蓋捐迫， 導(dǎo)致數(shù)據(jù)不一致乾翔。
6.6 阻塞
// 例子沒有成功， 插入時(shí)有鎖生成施戴。 select * from t where a<4 for update
// 4 是表里的最大值反浓， 4 到正無窮， 均被鎖了赞哗， 所以該表中均不可插入勾习。
innodb_lock_wait_timeout 用來控制等待的時(shí)間， 默認(rèn)是 50 秒懈玻。
默認(rèn)情況下巧婶， innodb 不會回滾超時(shí)引發(fā)的錯(cuò)誤異常。
6.7 死鎖
6.7.1 死鎖的概念
死鎖是指兩個(gè)或兩個(gè)以上的事務(wù)在執(zhí)行過程中涂乌， 因?yàn)闋帄Z資源而造成的一種互相等待的現(xiàn)象艺栈。 若無外力作用， 事務(wù)都將無法推進(jìn)下去湾盒。
解決死鎖問題最簡單的一種方法是超時(shí)湿右。
當(dāng)前數(shù)據(jù)庫普遍采用 wait-for graph 的方式來進(jìn)行死鎖檢測。
6.7.2 死鎖的概率
系統(tǒng)中任何一個(gè)事務(wù)發(fā)生死鎖的概率 約等于 n^2 * r^4 / 4 * R^2?
系統(tǒng)中事務(wù)的數(shù)量（n）,數(shù)量越多發(fā)生死鎖的概率越大罚勾。
每個(gè)事務(wù)操作的數(shù)量（r）, 每個(gè)事務(wù)操作的數(shù)量越多毅人， 發(fā)生死鎖的概率越大吭狡。
操作事務(wù)的集合（R）， 越小發(fā)生死鎖概率越大丈莺。
注：每個(gè)操作從 R 行數(shù)據(jù)中取一條數(shù)據(jù)划煮， 每行數(shù)據(jù)被取到的概率為 1 / R.
6.7.3 死鎖的示例
InnoDB 存儲引擎并不會回滾大部分的錯(cuò)誤異常， 但是死鎖除外缔俄。
InnoDB 引擎會自動對外鍵添加索引弛秋， 因而能夠很好的避免死鎖發(fā)生。 // 待理解
6.8 鎖升級（待理解）
鎖升級（Lock Escalation）是指將當(dāng)前鎖的粒度降低俐载。如數(shù)據(jù)庫把一個(gè)表的 1000 行鎖升級為一個(gè)頁鎖蟹略， 或?qū)㈨撴i升級為表鎖，來避免鎖的開銷遏佣。
InnoDB 引擎不存在鎖的升級問題挖炬。 因?yàn)槠洳皇歉鶕?jù)每個(gè)記錄來產(chǎn)生行鎖的， 相反状婶， 其根據(jù)每個(gè)事務(wù)訪問的每個(gè)頁對鎖進(jìn)行管理的茅茂， 采用位圖的方式。 因此不管一個(gè)事務(wù)鎖住一個(gè)記錄還是多個(gè)記錄太抓， 其開銷通常都是一致的空闲。
