隔離級别是在多個事務同時進行更改和執行查詢時，對性能與結果的可靠性、一緻性和再現性之間的平衡進行微調的設定。
提供了SQL:1992标準中描述的四種事務隔離級别：READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。InnoDB預設的隔離級别是REPEATABLE READ。
InnoDB使用不同的鎖定政策支援這裡描述的每個事務隔離級别。下面的清單描述了MySQL如何支援不同的事務級别。
1. REPEATABLE READ（可重複讀）
這是InnoDB的預設隔離級别。同一個事務中的一緻性讀取讀的是第一次讀取時建立的快照。這意味着，如果在同一個事務中發出幾個普通(非鎖定)SELECT語句，這些SELECT語句彼此之間也是一緻的。（PS：可重複讀這個級别就是要保證同一個事務中，多次讀取相同的資料，傳回的結果是一樣的。）
對于鎖定讀（SELECT with FOR UPDATE or LOCK IN SHARE MODE）、UPDATE 和 DELETE 語句，鎖定取決于語句是使用具有唯一搜尋條件的唯一索引，還是使用範圍類型的搜尋條件。
- 對于具有唯一搜尋條件的唯一索引，InnoDB隻鎖定找到的索引記錄，而不鎖定之間的間隙。
- 對于其他搜尋條件，InnoDB鎖定掃描到的索引範圍，使用間隙鎖或next-key鎖以阻止其他會話向該範圍覆寫的間隙中插入。
2. READ COMMITTED（讀已送出）
即使在同一事務中，每個一緻的讀取都将設定并讀取自己的新快照。（PS：對比一下，對于一緻性讀，可重複讀是讀取事務中第一次讀取時候建立的快照；而讀已送出，每次都是讀最新的快照）
對于鎖讀（SELECT with For UPDATE or LOCK IN SHARE MODE）、UPDATE語句和DELETE語句，InnoDB隻鎖住索引記錄，而不鎖住它們之間的間隙，進而允許在鎖住的記錄旁邊自由插入新記錄。間隙鎖定僅用于外鍵限制檢查和重複鍵檢查。
由于禁用了間隙鎖，可能會出現幻像問題，因為其他會話可以在間隙中插入新行。
使用READ COMMITTED具有額外的效果：
- 對于UPDATE或DELETE語句，InnoDB僅對其更新或删除的行持有鎖。MySQL評估WHERE條件後，将釋放不比對行的記錄鎖。這大大降低了死鎖的可能性，但是仍然可能發生。
- 對于UPDATE語句，如果某行已被鎖定，則InnoDB執行“半一緻”讀取，将最新的送出版本傳回給MySQL，以便MySQL可以确定該行是否與UPDATE的WHERE條件比對。如果該行比對（必須更新），則MySQL會再次讀取該行，這一次InnoDB将其鎖定或等待對其進行鎖定。
舉個例子，考慮下面的語句：
CREATE TABLE t (a INT NOT NULL, b INT) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT; 在這種情況下，表沒有索引，是以搜尋和索引掃描使用隐藏的聚集索引鎖定記錄
假設，第一個會話要執行update語句：
# Session A
START TRANSACTION;
UPDATE t SET b = 5 WHERE b = 3; 假設，在第一個會話之後，第二個會話也要執行如下update語句：
# Session B
UPDATE t SET b = 4 WHERE b = 2; 當InnoDB執行每個UPDATE時，它首先為讀取的每一行擷取一個排他鎖，然後決定是否修改它。如果InnoDB沒有修改該行，則釋放鎖。否則，InnoDB會保留鎖直到事務結束。這對事務處理的影響如下。
如果用預設的REPEATABLE READ隔離級别，第一個UPDATE在其讀取的每一行上擷取一個X鎖，并且不釋放其中的任何一個：
x-lock(1,2); retain x-lock
x-lock(2,3); update(2,3) to (2,5); retain x-lock
x-lock(3,2); retain x-lock
x-lock(4,3); update(4,3) to (4,5); retain x-lock
x-lock(5,2); retain x-lock （PS：之是以每一行都加排它鎖，是因為b上沒有唯一索引）
第二個UPDATE在嘗試擷取任何鎖時立即阻塞（因為第一個UPDATE已在所有行上保留了鎖），并且直到第一個UPDATE送出或復原後才繼續進行：
x-lock(1,2); block and wait for first UPDATE to commit or roll back 如果用READ COMMITTED隔離級别，第一個UPDATE在其讀取的每一行上擷取一個X鎖，并為未修改的行釋放X鎖：
x-lock(1,2); unlock(1,2)
x-lock(2,3); update(2,3) to (2,5); retain x-lock
x-lock(3,2); unlock(3,2)
x-lock(4,3); update(4,3) to (4,5); retain x-lock
x-lock(5,2); unlock(5,2) 但是，如果WHERE條件包含一個索引列，并且InnoDB使用該索引，那麼在擷取和保留記錄鎖時，隻考慮索引列。
再看下面一個例子，第一個UPDATE在b = 2的每一行上擷取并保留一個X鎖。第二個UPDATE在嘗試擷取同一記錄上的X鎖時會阻塞，因為它也使用在b列上定義的索引 。
CREATE TABLE t (a INT NOT NULL, b INT, c INT, INDEX (b)) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2,3),(2,2,4);
COMMIT;
# Session A
START TRANSACTION;
UPDATE t SET b = 3 WHERE b = 2 AND c = 3;
# Session B
UPDATE t SET b = 4 WHERE b = 2 AND c = 4; （PS：b列上有索引，這兩條語句在檢索時使用了b列上的索引，是以第一會話在b=2的列上加了X鎖，第一個會話更新b=2時會阻塞）
3. READ UNCOMMITTED（讀未送出）
會出現髒讀，一般不使用
4. SERIALIZABLE（串行化）
此級别類似于REPEATABLE READ，但如果禁用了自動送出，則InnoDB會将所有普通的SELECT語句隐式轉換為SELECT ... LOCK IN SHARE MODE。