MVCC 的基本模型:
Row: [key, value, version_chain]

version_chain:
v3 → v2 → v1 → v0
↑    ↑    ↑    ↑
tx3  tx2  tx1  tx0 (创建该版本的事务)

事务 tx4 (Read Committed):
→ 看到 v3 (最新的已提交版本)

事务 tx2 (Repeatable Read, 开始于 v2 之后):
→ 看到 v2 (事务开始时的快照)

InnoDB 行格式:
┌──────────────────────────────────────────┐
│ DB_TRX_ID (6B) | DB_ROLL_PTR (7B) | ... │  ← 当前版本
├──────────────────────────────────────────┤
│          User Columns                    │
└──────────────────────────────────────────┘

Undo Log (版本链):
Current Row (trx_id=100)
    ↓ roll_ptr
Undo Record (trx_id=80)
    ↓ roll_ptr
Undo Record (trx_id=50)
    ↓ roll_ptr
...

ReadView 结构:
┌─────────────────────────────────────────┐
│ creator_trx_id: 创建此 ReadView 的事务ID │
│ low_limit_id: 高水位线 (下一个将分配的事务ID) │
│ up_limit_id: 低水位线 (最小的活跃事务ID)    │
│ active_trx_ids: [活跃事务ID列表]          │
└─────────────────────────────────────────┘

可见性判断规则:
对于版本 v (trx_id = T):
1. T == creator_trx_id → 可见 (自己的修改)
2. T < up_limit_id → 可见 (事务已提交)
3. T >= low_limit_id → 不可见 (事务在 ReadView 创建后才开始)
4. T in active_trx_ids → 不可见 (事务还在活跃中)
5. 其他 → 可见 (事务已提交)

记录锁（Record Lock）:
- 锁定索引中的一条记录
- SELECT ... WHERE id = 1 FOR UPDATE → 锁住 id=1 这一行

间隙锁（Gap Lock）:
- 锁定索引记录之间的间隙
- 防止其他事务在间隙中插入新记录
- 用于防止幻读（Repeatable Read 级别）

临键锁（Next-Key Lock）:
- 记录锁 + 间隙锁的组合
- 锁定记录本身 + 记录之前的间隙
- InnoDB 在 Repeatable Read 级别下的默认锁策略

意向锁（Intention Lock）:
- 表级锁，表示事务打算对表中的记录加锁
- IS (Intention Shared): 打算加 S 锁
- IX (Intention Exclusive): 打算加 X 锁
- 用于快速检测表级锁冲突

IS    IX    S     X
IS      ✓     ✓     ✓     ✗
IX      ✓     ✓     ✗     ✗
S       ✓     ✗     ✓     ✗
IX      ✗     ✗     ✗     ✗

✓ = 兼容, ✗ = 冲突

等待图:
T1 → 持有锁A, 等待锁B
T2 → 持有锁B, 等待锁A

等待图:
T1 ──(等待B)──→ T2
T2 ──(等待A)──→ T1

检测到环 → 死锁!
解决方案: 回滚持有最少行锁的事务

事务提交流程 (InnoDB):
1. 将事务的 redo log 写入 log buffer
2. 调用 fsync 将 log buffer 刷入磁盘
3. 标记事务为已提交
4. 返回客户端

关键: 步骤 2 完成后事务才算真正提交
即使数据页还没有刷入磁盘，崩溃后也可以通过 redo log 恢复

ARIES 恢复算法 (三阶段):
1. 分析阶段 (Analysis):
   - 从最近的检查点开始扫描 redo log
   - 确定哪些事务在崩溃时是活跃的
   - 构建 Dirty Page Table

2. 重做阶段 (Redo):
   - 从分析阶段确定的起点开始
   - 重放所有 redo log 记录
   - 恢复所有已修改的页面（包括未提交事务的修改）

3. 撤销阶段 (Undo):
   - 对活跃事务（崩溃时未提交的）执行 undo 操作
   - 回滚未完成的修改
   - 保证原子性

-- 会话 1
BEGIN;
SELECT * FROM accounts WHERE id = 1;  -- balance = 100
-- ReadView: up_limit_id = 10, active = [5]

-- 会话 2
BEGIN;
UPDATE accounts SET balance = 200 WHERE id = 1;
-- trx_id = 15, 修改 balance 为 200
-- 旧版本 (balance=100, trx_id=10) 存入 undo log

-- 会话 1 (Repeatable Read)
SELECT * FROM accounts WHERE id = 1;
-- 仍然看到 balance = 100
-- 因为 trx_id=15 在 active_trx_ids 中 → 不可见

-- 会话 1 (Read Committed)
SELECT * FROM accounts WHERE id = 1;
-- 如果会话 2 已提交 → 看到 balance = 200
-- 因为每次 SELECT 创建新 ReadView, trx_id=15 已不在 active 中

-- 会话 1
BEGIN;
UPDATE accounts SET balance = balance + 100 WHERE id = 1;  -- 锁住 id=1
UPDATE accounts SET balance = balance - 100 WHERE id = 2;  -- 等待 id=2

-- 会话 2
BEGIN;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;  -- 锁住 id=2
UPDATE accounts SET balance = balance - 100 WHERE id = 1;  -- 等待 id=1 → 死锁!

-- InnoDB 检测到死锁, 回滚会话 2:
-- ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

-- 解决方案: 保证所有事务以相同的顺序访问资源
-- 会话 1 和 2 都先锁 id=1, 再锁 id=2 → 不会死锁