MySQL 事务隔离与 MVCC

每行数据隐含两个字段:
  DB_TRX_ID: 最近修改这行的事务 ID
  DB_ROLL_PTR: 指向 Undo Log 中旧版本的指针

Read View: 事务开始时创建的快照
  - m_ids: 当前活跃事务列表
  - min_trx_id: 最小活跃事务 ID
  - max_trx_id: 下一个将分配的事务 ID
  - creator_trx_id: 创建此 Read View 的事务 ID

START TRANSACTION;
-- 当前读：加排他锁，读取最新已提交数据
SELECT stock FROM products WHERE id = 1 FOR UPDATE;
-- stock = 10（最新值，不是快照）
UPDATE products SET stock = stock - 1 WHERE id = 1;
COMMIT;

-- 会话 A: REPEATABLE READ
START TRANSACTION;
SELECT * FROM users WHERE id = 1;  -- name='张三'

-- 会话 B: 修改并提交
UPDATE users SET name = '李四' WHERE id = 1;
COMMIT;

-- 会话 A: 再次查询
SELECT * FROM users WHERE id = 1;  -- 仍然是 '张三'（快照读）
SELECT * FROM users WHERE id = 1 FOR UPDATE;  -- '李四'（当前读）

-- 会话 A
START TRANSACTION;                    -- T1: 只标记事务开始，未创建 Read View
-- ... 其他事务在此期间提交 ...
SELECT * FROM users WHERE id = 1;     -- T2: 第一次快照读，创建 Read View
-- 此时 Read View 记录 T2 时刻的活跃事务列表

-- 如果 T2 之前会话 B 提交了修改，会话 A 能读到吗？能！
-- 因为 Read View 在 T2 才创建，T2 之前已提交的修改对 Read View 是可见的。

-- 第二次同样是快照读，复用同一个 Read View（RR 关键特性）
SELECT * FROM users WHERE id = 1;     -- T3: 复用 T2 的 Read View，结果不变

时间线（REPEATABLE READ 模式）：
─────────────────────────────────────────────────────────
事务A:  BEGIN         第一次SELECT        第二次SELECT    第三次SELECT
         |                |                  |               |
         |  不创建View     |  创建View #1     |  复用View #1  |  复用View #1
         |                |  (m_ids: [B,C])  |               |
事务B:      UPDATE COMMIT      |
事务C:              UPDATE ────|─── COMMIT
事务D:                         |  UPDATE ────── COMMIT
                               |
                         此时 Read View 记录:
                         m_ids = [A, C]   (B 已提交不在列表)
                         D 此时还不存在
                         
                         结果：B 的修改可见（创建时已提交）
                              C 的修改不可见（创建时活跃）
                              D 的修改不可见（创建时还不存在）

当前行（聚簇索引叶子页）：
┌──────────────────────────────────────────────┐
│ id=1 │ name='王五' │ DB_TRX_ID=300 │ DB_ROLL_PTR │──┐
└──────────────────────────────────────────────┘  │
                                                  ▼
Undo Log 版本链：
┌─────────────────────────────────────────────────────┐
│ [Undo Log Record #2]                                │
│ 旧值: name='李四'                                   │
│ DB_TRX_ID = 200                                     │
│ DB_ROLL_PTR ──────────────────────────┐             │
└────────────────────────────────────────┼────────────┘
                                         ▼
┌─────────────────────────────────────────────────────┐
│ [Undo Log Record #1]                                │
│ 旧值: name='张三'（最初值）                          │
│ DB_TRX_ID = 100                                     │
│ DB_ROLL_PTR = NULL（链尾）                           │
└─────────────────────────────────────────────────────┘

SELECT * FROM users WHERE id = 1;
→ 存储引擎读取聚簇索引中当前行
→ 检查 DB_TRX_ID = 300 对当前 Read View 是否可见

1. DB_TRX_ID = 300 < min_trx_id? → 否
2. DB_TRX_ID = 300 > max_trx_id? → 否  
3. DB_TRX_ID = 300 在 m_ids 中? → 是（事务 300 活跃）→ 不可见！

→ 沿着 DB_ROLL_PTR 读取 Undo Log Record #2
→ 检查 DB_TRX_ID = 200 是否可见

1. DB_TRX_ID = 200 < min_trx_id? → 是 → 可见！
→ 返回 name='李四'

Purge 工作流程：
1. 事务提交时，Undo Log 标记为"待清理"（而非立即删除）
2. Purge 线程定期扫描 Undo Log
3. 对每条 Undo Log Record，检查其 DB_TRX_ID：
   - 如果当前系统中**没有任何活跃 Read View 需要这个版本** → 物理删除
   - 如果仍有某个长事务的 Read View 的 min_trx_id 小于此 DB_TRX_ID → 保留
4. 清理后回收 Undo 表空间

为什么不是事务提交时立即删除？
  → 因为其他事务的快照读可能还需要这些旧版本（如 RR 的 Read View 在第一次SELECT时创建，后续SELECT仍需看到当时的数据）
  → 长事务会导致 Undo Log 膨胀（历史版本无法清理）

-- 危险的长事务
START TRANSACTION;
SELECT * FROM orders WHERE id = 1;  -- 创建 Read View，min_trx_id = 1000
-- ... 执行了 1 小时的业务逻辑 ...
-- ... 期间 orders 表被修改了 100 万次 ...
-- ... 所有 Undo Log 版本都因为 min_trx_id=1000 而无法被 Purge 清理 ...
COMMIT;  -- 此时 Purge 才能清理这些旧版本

-- 1. 显示锁定读
SELECT * FROM products WHERE id = 1 FOR UPDATE;          -- 排他锁（X 锁）
SELECT * FROM products WHERE id = 1 LOCK IN SHARE MODE;  -- 共享锁（S 锁）MySQL 8.0+ 用 FOR SHARE

-- 2. DML 的"读取"阶段（读取待修改的行时触发当前读）
UPDATE products SET stock = stock - 1 WHERE id = 1;  -- 内部先当前读，再加 X 锁，再修改
DELETE FROM orders WHERE id = 100;                    -- 同上
INSERT INTO orders (...) VALUES (...);                -- 检查唯一约束时触发当前读

-- 3. 外键检查
-- 插入子表行时，对父表引用行加 S 锁（当前读）

加锁规则总结表：

| 索引类型 | 查询类型 | 是否命中 | 实际加的锁 | 示例 |
|---------|---------|---------|-----------|------|
| 主键/唯一索引 | 等值 | 命中 | Record Lock | WHERE id=10 |
| 主键/唯一索引 | 等值 | 未命中 | Gap Lock | WHERE id=7 (表中无7) |
| 普通索引 | 等值 | 命中 | Next-Key Lock + 额外的 Gap Lock | WHERE user_id=5 |
| 普通索引 | 等值 | 未命中 | Gap Lock | WHERE user_id=7 |
| 任意索引 | 范围 | — | Next-Key Lock 多段 | WHERE id>10 AND id<20 |

死锁场景：
  事务A: 持有 id=10 的 X 锁，等待 id=20 的 X 锁
  事务B: 持有 id=20 的 X 锁，等待 id=10 的 X 锁

Wait-For Graph：
  事务A ──等待──→ 事务B
    ↑               │
    └──等待─────────┘

  检测到环 → 死锁！
  InnoDB 选择回滚"undo 量最小"的事务（通常是后开始的那个）

-- 表结构
CREATE TABLE products (
  id INT PRIMARY KEY,
  stock INT NOT NULL
);
INSERT INTO products VALUES (1, 100), (2, 50);

-- 会话 A（扣减商品 1 和 2 的库存）
START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE id = 1;  -- 锁住 id=1
-- 此时 A 持有 id=1 的 X 锁

-- 会话 B（扣减商品 2 和 1 的库存）  
START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE id = 2;  -- 锁住 id=2
-- 此时 B 持有 id=2 的 X 锁

-- 会话 A 继续
UPDATE products SET stock = stock - 1 WHERE id = 2;  -- 等待 B 释放 id=2 → 阻塞

-- 会话 B 继续
UPDATE products SET stock = stock - 1 WHERE id = 1;  -- 等待 A 释放 id=1 → 死锁！
-- ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

-- 查看最近死锁详情（包含涉及的事务、SQL、锁信息）
SHOW ENGINE INNODB STATUS\G
-- 滚动到 LATEST DETECTED DEADLOCK 段落

-- 查看当前活跃事务
SELECT * FROM information_schema.INNODB_TRX\G

-- MySQL 8.0+ 查看锁等待关系
SELECT 
  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,
  r.trx_query waiting_query,
  b.trx_id blocking_trx_id,
  b.trx_mysql_thread_id blocking_thread,
  b.trx_query blocking_query
FROM information_schema.INNODB_LOCK_WAITS w
JOIN information_schema.INNODB_TRX r ON w.requesting_trx_id = r.trx_id
JOIN information_schema.INNODB_TRX b ON w.blocking_trx_id = b.trx_id;

-- 方案 1：固定加锁顺序（最重要）
-- 规定所有事务必须先锁 id=1 再锁 id=2
-- ✅ 就不会出现 A 等 B、B 等 A 的情况

-- 方案 2：一次锁定所有需要的行
SELECT * FROM products WHERE id IN (1, 2) FOR UPDATE;  -- 此时按主键顺序加锁

-- 方案 3：应用层重试
try {
  // 执行事务
} catch (DeadlockLoserDataAccessException e) {
  // 休眠随机毫秒后重试
  Thread.sleep(random(10, 100));
  retry();
}

// 电商项目三 - 订单创建中的死锁预防
public void createOrder(Long userId, Long productId, Integer quantity) {
    // 策略 1：先锁商品再锁库存——所有订单统一顺序
    Product product = productMapper.selectForUpdate(productId);       // 1. 先锁商品
    Stock stock = stockMapper.selectForUpdate(product.getStockId()); // 2. 再锁库存
    
    // 策略 2：事务尽量短——不在事务中做 RPC 调用、发消息、写日志
    if (stock.getQuantity() >= quantity) {
        stockMapper.decreaseStock(stock.getId(), quantity);
        orderMapper.insert(new Order(userId, productId, quantity));
    }
    // 事务在此提交——不在事务中做其他耗时操作
}

隔离级别强度 vs 并发性能：

READ UNCOMMITTED        READ COMMITTED          REPEATABLE READ        SERIALIZABLE
    弱 ←──────────────────────────────────────────────────────────────→ 强
    高并发                                              	     	    低并发
[几乎不用]            [Oracle/PostgreSQL默认]    [MySQL InnoDB默认]        [极端需求]

RR 的临键锁在秒杀场景的副作用：

UPDATE products SET stock = stock - 1 WHERE id = 1;
  → 主键唯一索引等值命中 → 退化为 Record Lock → 只锁 id=1 这一行
  
  BUT！如果秒杀还有其他查询如：
  SELECT * FROM products WHERE stock > 0 FOR UPDATE;
  → 范围查询 → 加 Next-Key Lock 多段 → 大量间隙被锁 → 并发度骤降

// 项目三秒杀库存扣减 - RC + 乐观锁方案
@Transactional(rollbackFor = Exception.class)
public boolean decreaseStock(Long productId) {
    // 直接 UPDATE + WHERE 条件，不加 SELECT FOR UPDATE
    int affected = productMapper.decreaseStock(productId);
    // UPDATE products SET stock = stock - 1
    // WHERE id = #{productId} AND stock >= 1
    return affected > 0;  // affected=0 表示库存不足
}

START TRANSACTION;
SELECT stock FROM products WHERE id = 1;           -- 快照读 → stock=10
-- 另一个事务在此修改 stock 为 9 并提交
SELECT stock FROM products WHERE id = 1;           -- 快照读 → 仍是 10（复用 Read View）
SELECT stock FROM products WHERE id = 1 FOR UPDATE; -- 当前读 → stock=9（最新值）

长事务的连锁影响：

事务 A: BEGIN → SELECT (创建 Read View, min_trx_id = 100) → ... 1 小时后 COMMIT

1. Undo Log 膨胀：
   这 1 小时内，其他事务修改的所有行的旧版本（DB_TRX_ID >= 100）
   都因为事务 A 的 Read View 可能还需要 → Purge 线程无法清理
   → Undo Log 文件不断增长，可能耗尽磁盘

2. 锁持有时间：
   如果事务 A 中执行了 UPDATE/DELETE/SELECT FOR UPDATE
   → 行锁/临键锁持有 1 小时 → 大量其他事务排队等待 → 连接池耗尽

3. 从库延迟：
   MySQL binlog 在事务 COMMIT 时才写入
   → 1 小时内从库收不到任何该连接相关的 binlog 事件
   → 从库延迟增大（虽然其他事务正常同步）

4. 从库一致性：
   如果从库并行复制，长事务提交瞬间可能产生大量的 binlog 事件
   → 从库回放压力大

MVCC 能解决的：
  事务A 读 X ──→ 事务B 同时写 X ──→ A 读到旧版本，不被阻塞 ✅

MVCC 不能解决的：
  事务A 写 X ──→ 事务B 同时写 X ──→ 必须等 A 释放锁 ❌（写写冲突）

为什么写写冲突不能靠 MVCC？
  → 因为最终数据页上只能有 1 个版本
  → LOST UPDATE 问题：如果没有锁，A 和 B 同时读 stock=10，
     A 改成 9，B 改成 8 —— 应该变成 7，但变成 8（后写入覆盖前写入）