一、前提
1、MySQL版本：5.7.19
2、引擎：InnoDB
3、隔離機制：可重復讀。
二、不可重復讀與幻讀的區(qū)別
1、不可重復讀 ：同一事務中，多次讀取操作，前后的讀取結(jié)果不一樣。
2、幻讀 : 兩事務A、B，A對表T全部記錄做了某項操作，B對T的某些記錄做了操作，導致A幻讀。
3、演示：
1)、不可重復讀
事務1:
事務2:
結(jié)論：事務1在事務2修改前后，查出來的記錄是不一樣的，不可重復讀取。
2）幻讀
事務1:
事務2:
結(jié)論：事務1對所有檢索的記錄做了修改，事務2插入一條記錄，事務1再查詢時，發(fā)現(xiàn)還有記錄并未修改，發(fā)生幻讀。
OK！至此，不可重復讀與幻讀的區(qū)別應該能較容易區(qū)分了。
三、InnoDB的鎖機制
1、鎖類型及關系
Mysql InnoDB支持多種鎖，今天分享兩類。行鎖實了兩種類型的鎖：共享鎖（Shared Lock - S）和排他鎖（Exclusive Lock - X）;我們知道InnoDB實現(xiàn)了多粒度鎖級別鎖定，允許行鎖和表鎖共存，而這實際上是使用了其他類型的鎖，稱之為意向鎖（Intention Locks）。意向鎖是表鎖，分為意向共享鎖（Intention shared-IS）和意向排他鎖（Intention exclusive-IX）。
共享鎖（S）：允許一個事務去讀一行，阻止其他事務獲得相同數(shù)據(jù)集的排
他鎖。
排他鎖（X)：允許獲得排他鎖的事務更新數(shù)據(jù)，阻止其他事務取得相同數(shù)
據(jù)集的共享讀鎖和排他寫鎖。
意向共享鎖（IS）：事務打算給數(shù)據(jù)行加行共享鎖，事務在給一個數(shù)據(jù)行加
共享鎖前必須先取得該表的IS鎖。
意向排他鎖（IX）：事務打算給數(shù)據(jù)行加行排他鎖，事務在給一個數(shù)據(jù)行加
排他鎖前必須先取得該表的IX鎖。
他們的兼容關系如下：
如果一個事務請求的鎖模式與當前的鎖兼容，InnoDB就將請求的鎖授予該事務；反之，如果兩者不兼容，該事務就要等待鎖釋放。
注意：
1、意向鎖是InnoDB自動加的，不需用戶干預。對于UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數(shù)據(jù)集加排他鎖（X)；對于普通SELECT語句，InnoDB不會加任何鎖；
2、事務顯示獲取記錄集鎖：
共享鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
排他鎖（X)：SELECT * FROM table_name WHERE ... FOR UPDATE。
3、意圖鎖不會阻塞所有表請求，IX和IS的主要目的是表示某事務鎖定了一行，或?qū)㈡i定表中的一行。
下面將演示一個共享鎖的例子：
分析：
T1.3 等待T2.2' 的釋放共享鎖鎖以便獲取到排他鎖，而T2.4又等待T1.3釋放排他鎖，因此導致了死鎖，因此被 InnoDB 檢測到了，報了個 DeadLock ERROR
在上面的例子中，兩個事務都需要獲得對方持有的排他鎖才能繼續(xù)完成事務，這種循環(huán)鎖等待就是典型的死鎖。發(fā)生死鎖后，InnoDB一般都能自動檢測到，并使一個事務釋放鎖并回退，另一個事務獲得鎖，繼續(xù)完成事務。
排他鎖的例子：
分析：
在T1的3處給記錄加排他鎖，T2的4處將無法獲取該鎖，只能等待；待T1的擁有鎖的4更新完，5處將獲取鎖并獲取T1更新后的記錄。而在T2等待的時候報錯了-“ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction”，這個報錯是很有必要的，在后續(xù)的死鎖介紹時會詳細說到，盡管InnoDB大多情況下能自我檢測死鎖，但是有些情況并不能，此時可通過設置“innodb_lock_wait_timeout”參數(shù)來解決。
需要說明的是，這個參數(shù)并不是只用來解決死鎖問題，在并發(fā)訪問比較高的情況下，如果大量事務因無法立即獲得所需的鎖而掛起，會占用大量計算機資源，造成嚴重性能問題，甚至拖跨數(shù)據(jù)庫。我們通過設置合適的鎖等待超時閾值，可以避免這種情況發(fā)生。InnoDB 默認設置為50s。
好了，本次分享到此，下次分享InnoDB行鎖實現(xiàn)方式以及其他鎖簡介。
