MySQL 事務隔離級別完整圖解與實戰驗證指南

四大隔離級別標準定義

MySQL 默認： REPEATABLE READ

修改隔離級別的兩種方式

1. 全局永久修改 (my.cnf)

[mysqld]
transaction-isolation = REPEATABLE-READ
# 可選值：READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE

修改後重啟 MySQL 生效。

2. 當前會話臨時修改

-- 當前會話
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 全局 (需 SUPER 權限，重啟失效)
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 查看當前級別
SELECT @@tx_isolation;          -- 會話級別
SELECT @@global.tx_isolation;   -- 全局級別

關鍵參數：autocommit

SELECT @@autocommit;  -- 默認 ON (1)
SET autocommit = 0;   -- 關閉自動提交，手動管理事務

重大影響： autocommit=ON 時，每條語句隱式事務，**行鎖在語句結束即釋放**，SELECT ... FOR UPDATE 等鎖語句**完全失效** (鎖獲取後立即釋放)。**務必在顯式事務 (START TRANSACTION) 中使用鎖語句**。

鎖類型速查

實戰驗證：雙會話模擬各級別行為

環境： InnoDB 表 user(id, name, age)，會話 A 設置級別並查詢，會話 B 修改數據。

1. READ UNCOMMITTED

1. A: SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; START TRANSACTION; SELECT * FROM user WHERE id=1;
2. B: START TRANSACTION; UPDATE user SET age=20 WHERE id=1; -- 未提交
3. A: 再次查詢 → **看到 B 未提交的修改 (髒讀)**
4. B: ROLLBACK;
5. A: 再次查詢 → **數據變回原值**
6. A 修改數據 → B 修改同行掛起，修改他行成功 → **A 持有行共享鎖**

結論： 最不安全，但寫操作仍加行共享鎖。

2. READ COMMITTED

1. A 設置 RC，查詢
2. B 修改未提交 → A 查詢**不受影響**
3. B 提交 → A 查詢**看到新值 (不可重複讀)**
4. A 修改 → B 修改同行掛起，他行成功 → **行共享鎖**

結論： 只有提交後可見，寫操作加行共享鎖。

3. REPEATABLE READ (默認)

1. A 設置 RR，查詢
2. B 修改並提交 → A 查詢**仍見舊值 (可重複讀)**
3. A 提交後再查 → **見新值**
4. A 修改 → B 修改同行掛起，他行成功 → **行共享鎖持有到事務結束**

結論： 事務內建立一致性快照，寫操作加行共享鎖直到提交。

4. SERIALIZABLE

1. A 設置 Serializable，查詢
2. B 普通查詢 → **正常** (兼容共享鎖)
3. B 開啟事務修改 → **掛起等待** (A 的查詢加了表/行共享鎖，阻塞 X 鎖)

結論： 最嚴格，**讀操作即加共享鎖**，寫操作完全串行，並發效能極低。

隔離級別與鎖的對應關係總結

選型建議

• 95% 場景： 保持默認 REPEATABLE READ，安全且效能可接受
• 高並發讀多、可容忍不可重複讀： 改 READ COMMITTED，減少 Gap Lock 開銷，提升並發
• 嚴格財務對賬、報表： 考慮 SERIALIZABLE 或應用層邏輯鎖
• 絕不使用： READ UNCOMMITTED (髒讀風險不可控)