MySQL/InnoDB定義的4種隔離級別：
Read Uncommited
可以讀取未提交記錄。此隔離級別，不會使用，忽略。
Read Committed (RC)
快照讀忽略，本文不考慮。
針對當前讀，RC隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，存在幻讀現象。
Repeatable Read (RR)
快照讀忽略，本文不考慮。
針對當前讀，RR隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，同時保證對讀取的范圍加鎖，新的滿足查詢條件的記錄不能夠插入 (間隙鎖)，不存在幻讀現象。
Serializable
從MVCC並發控制退化為基於鎖的並發控制。不區別快照讀與當前讀，所有的讀操作均為當前讀，讀加讀鎖 (S鎖)，寫加寫鎖 (X鎖)。
Serializable隔離級別下，讀寫沖突，因此並發度急劇下降，在MySQL/InnoDB下不建議使用。
1. 數據庫事務ACID特性
數據庫事務的4個特性：
原子性(Atomic): 事務中的多個操作，不可分割，要么都成功，要么都失敗； All or Nothing.
一致性(Consistency): 事務操作之后, 數據庫所處的狀態和業務規則是一致的; 比如a,b賬戶相互轉賬之后，總金額不變；
隔離性(Isolation): 多個事務之間就像是串行執行一樣，不相互影響;
持久性(Durability): 事務提交后被持久化到永久存儲.
2. 隔離性
其中 隔離性 分為了四種：
READ UNCOMMITTED：可以讀取未提交的數據，未提交的數據稱為臟數據，所以又稱臟讀。此時：幻讀，不可重復讀和臟讀均允許；
READ COMMITTED：只能讀取已經提交的數據；此時：允許幻讀和不可重復讀，但不允許臟讀，所以RC隔離級別要求解決臟讀；
REPEATABLE READ：同一個事務中多次執行同一個select,讀取到的數據沒有發生改變；此時：允許幻讀，但不允許不可重復讀和臟讀，所以RR隔離級別要求解決不可重復讀；
SERIALIZABLE: 幻讀，不可重復讀和臟讀都不允許，所以serializable要求解決幻讀；
3. 幾個概念
臟讀：可以讀取未提交的數據。RC 要求解決臟讀；
不可重復讀：同一個事務中多次執行同一個select, 讀取到的數據發生了改變(被其它事務update並且提交)；
可重復讀：同一個事務中多次執行同一個select, 讀取到的數據沒有發生改變(一般使用MVCC實現)；RR各級級別要求達到可重復讀的標准；
幻讀：同一個事務中多次執行同一個select, 讀取到的數據行發生改變。也就是行數減少或者增加了(被其它事務delete/insert並且提交)。SERIALIZABLE要求解決幻讀問題；
這里一定要區分 不可重復讀 和 幻讀：
不可重復讀的重點是修改:
同樣的條件的select, 你讀取過的數據, 再次讀取出來發現值不一樣了
幻讀的重點在於新增或者刪除:
同樣的條件的select, 第1次和第2次讀出來的記錄數不一樣
從結果上來看, 兩者都是為多次讀取的結果不一致。但如果你從實現的角度來看, 它們的區別就比較大：
對於前者, 在RC下只需要鎖住滿足條件的記錄，就可以避免被其它事務修改，也就是 select for update, select in share mode; RR隔離下使用MVCC實現可重復讀；
對於后者, 要鎖住滿足條件的記錄及所有這些記錄之間的gap，也就是需要 gap lock。
而ANSI SQL標准沒有從隔離程度進行定義，而是定義了事務的隔離級別，同時定義了不同事務隔離級別解決的三大並發問題：
| Isolation Level |
Dirty Read |
Unrepeatable Read |
Phantom Read |
| Read UNCOMMITTED |
YES |
YES |
YES |
| READ COMMITTED |
NO |
YES |
YES |
| READ REPEATABLE |
NO |
NO |
YES |
| SERIALIZABLE |
NO |
NO |
NO |
參見：你真的明白事務的隔離性嗎？ (姜承堯)
4. 數據庫的默認隔離級別
除了MySQL默認采用RR隔離級別之外，其它幾大數據庫都是采用RC隔離級別。
但是他們的實現也是極其不一樣的。Oracle僅僅實現了RC 和 SERIALIZABLE隔離級別。默認采用RC隔離級別，解決了臟讀。但是允許不可重復讀和幻讀。其SERIALIZABLE則解決了臟讀、不可重復讀、幻讀。
MySQL的實現：MySQL默認采用RR隔離級別，SQL標准是要求RR解決不可重復讀的問題，但是因為MySQL采用了gap lock，所以實際上MySQL的RR隔離級別也解決了幻讀的問題。那么MySQL的SERIALIZABLE是怎么回事呢？其實MySQL的SERIALIZABLE采用了經典的實現方式，對讀和寫都加鎖。
5. MySQL 中RC和RR隔離級別的區別
MySQL數據庫中默認隔離級別為RR，但是實際情況是使用RC 和 RR隔離級別的都不少。好像淘寶、網易都是使用的 RC 隔離級別。那么在MySQL中 RC 和 RR有什么區別呢？我們該如何選擇呢？為什么MySQL將RR作為默認的隔離級別呢？
5.1 RC 與 RR 在鎖方面的區別
1> 顯然 RR 支持 gap lock(next-key lock)，而RC則沒有gap lock。因為MySQL的RR需要gap lock來解決幻讀問題。而RC隔離級別則是允許存在不可重復讀和幻讀的。所以RC的並發一般要好於RR；
2> RC 隔離級別，通過 where 條件過濾之后，不符合條件的記錄上的行鎖，會釋放掉(雖然這里破壞了“兩階段加鎖原則”)；但是RR隔離級別，即使不符合where條件的記錄，也不會是否行鎖和gap lock；所以從鎖方面來看，RC的並發應該要好於RR；另外 insert into t select ... from s where 語句在s表上的鎖也是不一樣的，參見下面的例子2；
例子1：
MySQL5.6, 隔離級別RR，autocommit=off;
表結構：
mysql> show create table t1\G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`a` int(11) NOT NULL,
`b` int(11) NOT NULL,
`c` int(11) NOT NULL,
`d` int(11) NOT NULL,
`e` varchar(20) DEFAULT NULL,
PRIMARY KEY (`a`),
KEY `idx_t1_bcd` (`b`,`c`,`d`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
表數據：
mysql> select * from t1; +---+---+---+---+------+ | a | b | c | d | e | +---+---+---+---+------+ | 1 | 1 | 1 | 1 | a | | 2 | 2 | 2 | 2 | b | | 3 | 3 | 2 | 2 | c | | 4 | 3 | 1 | 1 | d | | 5 | 2 | 3 | 5 | e | | 6 | 6 | 4 | 4 | f | | 7 | 4 | 5 | 5 | g | | 8 | 8 | 8 | 8 | h | +---+---+---+---+------+ 8 rows in set (0.00 sec)
操作過程：
session 1:
delete from t1 where b>2 and b<5 and c=2;
執行計划如下：
mysql> explain select * from t1 where b>2 and b<5 and c=2\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
type: range
possible_keys: idx_t1_bcd
key: idx_t1_bcd
key_len: 4
ref: NULL
rows: 2
Extra: Using index condition
1 row in set (0.00 sec)
session 2:
delete from t1 where a=4
結果 session 2 被鎖住。
session 3:
mysql> select * from information_schema.innodb_locks; +---------------+-------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+ | lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data | +---------------+-------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+ | 38777:390:3:5 | 38777 | X | RECORD | `test`.`t1` | PRIMARY | 390 | 3 | 5 | 4 | | 38771:390:3:5 | 38771 | X | RECORD | `test`.`t1` | PRIMARY | 390 | 3 | 5 | 4 | +---------------+-------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+
-------
要理解這里為什么 a=4 被鎖住了，需要理解 gap lock，鎖處理 RR 隔離級別和RC隔離級別的區別等等。
這里的原因如下：
很簡單，我們注意到：key_len: 4 和 Extra: Using index condition
這說明了，僅僅使用了索引 idx_t1_bcd 中的 b 一列，沒有使用到 c 這一列。c 這一列是在ICP時進行過濾的。所以：
delete from t1 where b>2 and b<5 and c=2 其實鎖定的行有：
mysql> select * from t1 where b>2 and b<=6; +---+---+---+---+------+ | a | b | c | d | e | +---+---+---+---+------+ | 3 | 3 | 2 | 2 | c | | 4 | 3 | 1 | 1 | d | | 6 | 6 | 4 | 4 | f | | 7 | 4 | 5 | 5 | g | +---+---+---+---+------+ 4 rows in set (0.00 sec)
所以顯然 delete from t1 where a=4 就被阻塞了。那么為什么 delete from t1 where a=6 也會被阻塞呢？？？
這里 b<=6 的原因是，b 列中沒有等於 5 的記錄，所以 and b<5 實現為鎖定 b<=6 的所有索引記錄，這里有等於號的原因是，如果我們不鎖定 =6 的索引記錄，那么怎么實���鎖定 <5 的gap 呢？也就是說鎖定 b=6 的索引記錄，是為了實現鎖定 b< 5 的gap。也就是不能刪除 b=6 記錄的原因。
而這里 b >2 沒有加等於號(b>=2) 的原因，是因為 b>2的這個gap 是由 b=3這個索引記錄(的gap)來實現的，不是由 b=2索引記錄(的gap) 來實現的，b=2的索引記錄的gap lock只能實現鎖定<2的gap，b>2的gap鎖定功能，需要由 b=3的索引記錄對應的gap來實現(b>2，b<3的gap)。
所以我們在session2中可以刪除：a=1,2,5,8的記錄，但是不能刪除 a=6(因為該行的b=6)的記錄。
如果我們使用 RC 隔離級別時，則不會發生阻塞，其原因就是：
RC和RR隔離級別中的鎖處理不一樣，RC隔離級別時，在使用c列進行ICP where條件過濾時，對於不符合條件的記錄，鎖會釋放掉，而RR隔離級別時，即使不符合條件的記錄，鎖也不會釋放(雖然違反了“2階段鎖”原則)。所以RC隔離級別時session 2不會被阻塞。
Gap lock: This is a lock on a gap between index records, or a lock on the gap before the first or after the last index record.
例子2：insert into t select ... from s where 在RC 和 RR隔離級別下的加鎖過程
下面是官方文檔中的說明：http://dev.mysql.com/doc/refman/5.6/en/innodb-locks-set.html
INSERT INTO T SELECT ... FROM S WHERE ... sets an exclusive index record lock (without a gap lock) on each row inserted into T. If the transaction isolation level is READ COMMITTED, or innodb_locks_unsafe_for_binlog is enabled and the transaction isolation level is not SERIALIZABLE, InnoDB does the search on S as a consistent read (no locks). Otherwise, InnoDB sets shared next-key locks on rows from S. InnoDB has to set locks in the latter case: In roll-forward recovery from a backup, every SQL statement must be executed in exactly the same way it was done originally.
CREATE TABLE ... SELECT ... performs the SELECT with shared next-key locks or as a consistent read, as for INSERT ... SELECT.
When a SELECT is used in the constructs REPLACE INTO t SELECT ... FROM s WHERE ... or UPDATE t ... WHERE col IN (SELECT ... FROM s ...), InnoDB sets shared next-key locks on rows from table s.
insert inot t select ... from s where ... 語句和 create table ... select ... from s where 加鎖過程是相似的(RC 和 RR 加鎖不一樣)：
1> RC 隔離級別時和 RR隔離級別但是設置innodb_locks_unsafe_for_binlog=1 時，select ... from s where 對 s 表進行的是一致性讀，所以是無需加鎖的；
2> 如果是RR隔離級別(默認innodb_locks_unsafe_for_binlog=0)，或者是 serializable隔離級別，那么對 s 表上的每一行都要加上 shared next-key lock.
這個區別是一個很大的不同，下面是生成中的一個 insert into t select ... from s where 導致的系統宕機的案例：
一程序猿執行一個分表操作：
insert into tb_async_src_acct_201508 select * from tb_async_src_acct where src_status=3 and create_time>='2015-08-01 00:00:00' and create_time <= '2015-08-31 23:59:59';
表 tb_async_src_acct有4000W數據。分表的目的是想提升下性能。結果一執行該語句，該條SQL被卡住，然后所有向 tb_async_src_acct的寫操作，要么是 get lock fail, 要么是 lost connection，全部卡住，然后主庫就宕機了。
顯然這里的原因，就是不知道默認RR隔離級別中 insert into t select ... from s where 語句的在 s 表上的加鎖過程，該語句一執行，所有符合 where 條件的 s 表中的行記錄都會加上 shared next-key lock(如果沒有使用到索引，還會鎖住表中所有行)，在整個事務過程中一直持有，因為表 tb_async_src_acct 數據很多，所以運行過程是很長的，所以加鎖過程也是很長，所以其它所有的對 tb_async_src_acct 的insert, delete, update, DDL 都會被阻塞掉，這樣被阻塞的事務就越來越多，而事務也會申請其它的表中的行鎖，結果就是系統中被卡住的事務越來越多，系統自然就宕機了。
5.2 RC 與 RR 在復制方面的區別
1> RC 隔離級別不支持 statement 格式的bin log，因為該格式的復制，會導致主從數據的不一致；只能使用 mixed 或者 row 格式的bin log; 這也是為什么MySQL默認使用RR隔離級別的原因。復制時，我們最好使用：binlog_format=row
具體參見：
http://www.linuxidc.com/Linux/2017-02/140846.htm
http://www.linuxidc.com/Linux/2017-02/140847.htm
2> MySQL5.6 的早期版本，RC隔離級別是可以設置成使用statement格式的bin log，后期版本則會直接報錯；
5.3 RC 與 RR 在一致性讀方面的區別
簡單而且，RC隔離級別時，事務中的每一條select語句會讀取到他自己執行時已經提交了的記錄，也就是每一條select都有自己的一致性讀ReadView; 而RR隔離級別時，事務中的一致性讀的ReadView是以第一條select語句的運行時，作為本事務的一致性讀snapshot的建立時間點的。只能讀取該時間點之前已經提交的數據。
具體可以參加：MySQL 一致性讀 深入研究
5.4 RC 支持半一致性讀，RR不支持
RC隔離級別下的update語句，使用的是半一致性讀(semi consistent)；而RR隔離級別的update語句使用的是當前讀；當前讀會發生鎖的阻塞。
1> 半一致性讀：
A type of read operation used for UPDATE statements, that is a combination of read committed and consistent read. When an UPDATE statement examines a row that is already locked, InnoDB returns the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE. If the row matches (must be updated), MySQL reads the row again, and this time InnoDB either locks it or waits for a lock on it. This type of read operation can only happen when the transaction has the read committed isolation level, or when the innodb_locks_unsafe_for_binlog option is enabled.
簡單來說，semi-consistent read是read committed與consistent read兩者的結合。一個update語句，如果讀到一行已經加鎖的記錄，此時InnoDB返回記錄最近提交的版本，由MySQL上層判斷此版本是否滿足 update的where條件。若滿足(需要更新)，則MySQL會重新發起一次讀操作，此時會讀取行的最新版本(並加鎖)。semi-consistent read只會發生在read committed隔離級別下，或者是參數innodb_locks_unsafe_for_binlog被設置為true(該參數即將被廢棄)。
對比RR隔離級別，update語句會使用當前讀，如果一行被鎖定了，那么此時會被阻塞，發生鎖等待。而不會讀取最新的提交版本，然后來判斷是否符合where條件。
半一致性讀的優點：
減少了update語句時行鎖的沖突；對於不滿足update更新條件的記錄，可以提前放鎖，減少並發沖突的概率。
https://blog.csdn.net/u014066037/article/details/68941287