前言：为什么需要深入理解 MySQL 底层技术？

模块一：B+ 树索引的底层实现与设计逻辑

1.1 B+ 树节点的内存结构与磁盘存储

1.1.1 节点结构的源码解析

// 页头部信息（所有类型页通用）
struct PageHeader {
    uint32_t page_no;          // 页编号（唯一标识）
    uint32_t prev_page;        // 上一页编号（双向链表）
    uint32_t next_page;        // 下一页编号
    uint16_t page_type;        // 页类型（索引页/数据页等）
    uint16_t space_id;         // 表空间ID
    uint32_t page_size;        // 页大小（默认16KB）
};

// B+树索引页的特有结构
struct BtreePage {
    PageHeader header;         // 页头部
    uint32_t level;            // 节点层级（0为叶子节点，>0为非叶子节点）
    uint32_t n_dir_slots;      // 目录槽数量（用于快速定位记录）
    uint32_t heap_top;         // 堆顶部位置（空闲空间起始点）
    uint32_t n_recs;           // 记录数量
    uint32_t max_recs;         // 最大记录数（受页大小限制）
    uint32_t del_mask;         // 删除掩码（标记已删除记录）
    uint32_t rec_ptr[0];       // 记录指针数组（指向实际记录）
};

// 索引记录结构（叶子节点）
struct IndexRecord {
    uint16_t len;              // 记录长度
    uint8_t* key;              // 索引键值
    uint64_t row_id;           // 数据行ID（非叶子节点为子页指针）
};

1.1.2 设计思路：为什么 B+ 树适合作为索引结构？

1. 磁盘 IO 优化
磁盘读写的最小单位是「扇区」（通常 512B），而 InnoDB 页大小为 16KB（相当于 32 个扇区）。B+ 树将节点大小设计为页大小，使得一次 IO 可加载整个节点，减少 IO 次数。

2. 有序性与二分查找
节点内的记录按键值有序排列，支持二分查找（时间复杂度 $O(\log n)$）。例如，一个包含 1000 条记录的节点，二分查找仅需 10 次比较即可定位目标。

3. 叶子节点链表化
叶子节点通过 prev_page 和 next_page 形成双向链表，支持范围查询（如 BETWEEN ... AND ...），无需回溯父节点。

4. 非叶子节点仅存键值
非叶子节点不存储实际数据，仅存储「索引键+子页指针」，使得单个节点可容纳更多键值，降低树的高度（通常 3-4 层即可支撑千万级数据）。

1.1.3 与其他数据结构的对比

1.1.4 实际业务中的索引设计启示

• 控制索引字段长度：索引键值越长，单个节点容纳的记录越少，树高越高。例如，VARCHAR(255) 比 INT 更易导致树高增加，建议对长字符串使用前缀索引（如 INDEX idx_name (name(10))）。

• 避免过度索引：每个索引对应一棵 B+ 树，过多索引会导致写入性能下降（每次写入需更新所有相关索引树）。

• 利用叶子节点链表：对频繁范围查询的场景（如按时间查询订单），设计有序索引可大幅提升效率。

1.2 B+ 树插入操作的全流程解析

1.2.1 插入流程的源码级伪代码

// 插入入口函数
int btr_insert(Btree* tree, const uint8_t* key, uint64_t row_id) {
    // 1. 查找插入位置（叶子节点）
    BtreePage* leaf = btr_find_leaf(tree, key);

    // 2. 尝试插入记录
    if (leaf->n_recs < leaf->max_recs) {
        btr_insert_into_page(leaf, key, row_id);
        return 0;
    }

    // 3. 节点满，触发分裂
    BtreePage* new_leaf = btr_split_page(leaf);

    // 4. 重新选择插入节点（原节点或新节点）
    BtreePage* target = (key_compare(key, new_leaf->min_key) < 0) ? leaf : new_leaf;
    btr_insert_into_page(target, key, row_id);

    // 5. 更新父节点
    return btr_update_parent(leaf, new_leaf);
}

// 节点分裂函数
BtreePage* btr_split_page(BtreePage* old_page) {
    // 1. 创建新节点
    BtreePage* new_page = page_alloc(old_page->header.space_id);
    new_page->level = old_page->level;
    new_page->header.prev_page = old_page->header.page_no;
    old_page->header.next_page = new_page->header.page_no;

    // 2. 分裂记录（平均分配）
    uint32_t mid = old_page->n_recs / 2;
    memcpy(new_page->rec_ptr + mid, old_page->rec_ptr + mid,
           (old_page->n_recs - mid) * sizeof(uint32_t));
    new_page->n_recs = old_page->n_recs - mid;
    old_page->n_recs = mid;

    // 3. 更新新节点的最小键
    new_page->min_key = old_page->rec_ptr[mid]->key;

    return new_page;
}

// 更新父节点
int btr_update_parent(BtreePage* old_page, BtreePage* new_page) {
    // 1. 查找父节点
    BtreePage* parent = btr_find_parent(old_page);

    // 2. 插入新节点的索引键
    if (parent->n_recs < parent->max_recs) {
        btr_insert_into_page(parent, new_page->min_key, new_page->header.page_no);
        return 0;
    }

    // 3. 父节点满，递归分裂
    return btr_split_and_update(parent, new_page);
}

1.2.2 插入流程的时序图

sequenceDiagram
    participant Client as 客户端
    participant Btree as B+树
    participant Leaf as 叶子节点(P1)
    participant NewLeaf as 新叶子节点(P2)
    participant Parent as 父节点(P0)

    Client->>Btree: 插入键值(key=100, row_id=500)
    Btree->>Leaf: 查找插入位置（P1）
    Leaf->>Btree: 节点已满（100条记录）
    Btree->>NewLeaf: 创建新节点(P2)
    Btree->>Leaf: 分裂记录（前50条保留）
    Btree->>NewLeaf: 分裂记录（后50条迁移）
    Btree->>Leaf: 更新指针(P1.next=P2)
    Btree->>NewLeaf: 更新指针(P2.prev=P1)
    Btree->>Parent: 插入新键(key=P2.min_key, ptr=P2)
    Parent->>Btree: 父节点未满，插入成功
    Btree->>Client: 插入完成

1.2.3 插入操作的性能瓶颈与优化

• 节点分裂的开销：分裂需复制记录、更新指针，是插入性能的主要瓶颈。在批量插入场景（如数据迁移），可通过「预排序数据」减少分裂（有序插入可使节点填满后再分裂，避免频繁分裂）。

• 并发插入的锁竞争：InnoDB 对插入位置加锁（INSERT INTENTION LOCK），高并发下可能导致锁等待。建议对热点表分表（如按用户 ID 哈希分表），分散插入压力。

• 自增主键的优势：自增主键（AUTO_INCREMENT）的插入始终在叶子节点末尾，无需查找插入位置，且分裂可预测（仅右侧节点分裂），性能优于随机主键。

1.3 B+ 树查询操作的底层逻辑

1.3.1 查询流程的源码级伪代码

// 查找单条记录
IndexRecord* btr_search(Btree* tree, const uint8_t* key) {
    BtreePage* current = tree->root;

    // 1. 从根节点逐层向下查找
    while (current->level > 0) {
        // 二分查找子节点
        uint32_t slot = btr_binary_search(current, key);
        current = btr_load_page(current->rec_ptr[slot]->row_id); // row_id此处为子页指针
    }

    // 2. 在叶子节点查找目标记录
    uint32_t pos = btr_binary_search(current, key);
    if (pos < current->n_recs && key_compare(current->rec_ptr[pos]->key, key) == 0) {
        return current->rec_ptr[pos];
    }

    return NULL; // 未找到
}

// 二分查找节点内记录
uint32_t btr_binary_search(BtreePage* page, const uint8_t* key) {
    uint32_t low = 0, high = page->n_recs - 1;
    while (low <= high) {
        uint32_t mid = (low + high) / 2;
        int cmp = key_compare(page->rec_ptr[mid]->key, key);
        if (cmp == 0) return mid;
        else if (cmp < 0) low = mid + 1;
        else high = mid - 1;
    }
    return low; // 插入位置
}

// 范围查询
void btr_range_search(Btree* tree, const uint8_t* start, const uint8_t* end, ResultSet* result) {
    BtreePage* current = tree->root;

    // 1. 定位起始叶子节点
    while (current->level > 0) {
        uint32_t slot = btr_binary_search(current, start);
        current = btr_load_page(current->rec_ptr[slot]->row_id);
    }

    // 2. 遍历叶子节点链表
    while (current != NULL) {
        // 3. 扫描当前节点内符合条件的记录
        for (uint32_t i = 0; i < current->n_recs; i++) {
            IndexRecord* rec = current->rec_ptr[i];
            if (key_compare(rec->key, start) >= 0 && key_compare(rec->key, end) <= 0) {
                result->add(rec);
            } else if (key_compare(rec->key, end) > 0) {
                current = NULL; // 超出范围，终止
                break;
            }
        }
        current = btr_load_page(current->header.next_page); // 下一页
    }
}

1.3.2 查询流程的时序图（单条查询）

sequenceDiagram
    participant Query as 查询请求
    participant Root as 根节点(P3)
    participant NonLeaf as 非叶子节点(P2)
    participant Leaf as 叶子节点(P1)

    Query->>Root: 查找key=100
    Root->>Root: 二分查找（定位子节点P2）
    Root->>NonLeaf: 跳转至P2
    NonLeaf->>NonLeaf: 二分查找（定位子节点P1）
    NonLeaf->>Leaf: 跳转至P1
    Leaf->>Leaf: 二分查找（找到key=100）
    Leaf->>Query: 返回row_id=500

1.3.3 查询流程的时序图（范围查询）

sequenceDiagram
    participant Query as 查询请求(key BETWEEN 50 AND 150)
    participant Leaf1 as 叶子节点(P1)
    participant Leaf2 as 叶子节点(P2)
    participant Leaf3 as 叶子节点(P3)

    Query->>Leaf1: 定位起始节点（key=50所在P1）
    Leaf1->>Query: 返回P1中符合条件的记录(50-100)
    Leaf1->>Leaf2: 跳转至下一页(P2)
    Leaf2->>Query: 返回P2中符合条件的记录(101-150)
    Leaf2->>Leaf3: 跳转至下一页(P3)
    Leaf3->>Query: P3中无符合条件记录（151+）
    Leaf3->>Query: 终止查询

1.3.4 影响查询性能的关键因素

1. 树的高度：树高每增加 1，IO 次数增加 1。例如：
• 树高 3：最多 3 次 IO（根节点通常缓存于内存，实际 2 次 IO）。
• 千万级数据：B+ 树高约 3（假设每个节点 1000 条记录：$1000^3 = 10^9$）。

2. 缓存命中率：InnoDB 的缓冲池（Buffer Pool）会缓存热点页，命中缓存可避免磁盘 IO。建议将缓冲池大小设置为物理内存的 50%-70%（如 16GB 内存分配 10GB 缓冲池）。

3. 索引覆盖度：若查询字段均可从索引获取（覆盖索引），无需回表查询数据行，性能可提升 10-100 倍。

1.4 B+ 树删除操作与节点合并

1.4.1 删除流程的伪代码

// 删除入口函数
int btr_delete(Btree* tree, const uint8_t* key) {
    // 1. 查找记录所在节点
    BtreePage* leaf = btr_find_leaf(tree, key);
    IndexRecord* rec = btr_find_record(leaf, key);
    if (rec == NULL) return -1; // 记录不存在

    // 2. 标记删除（延迟物理删除）
    rec->deleted = 1;
    leaf->n_recs--;

    // 3. 检查节点是否需要合并
    if (leaf->n_recs < MIN_RECS && leaf->level == 0) { // 叶子节点且记录过少
        BtreePage* prev = btr_load_page(leaf->header.prev_page);
        BtreePage* next = btr_load_page(leaf->header.next_page);

        // 优先合并前序节点
        if (prev != NULL && prev->n_recs + leaf->n_recs <= MAX_RECS) {
            btr_merge_pages(prev, leaf);
            return 0;
        }

        // 其次合并后序节点
        if (next != NULL && next->n_recs + leaf->n_recs <= MAX_RECS) {
            btr_merge_pages(leaf, next);
            return 0;
        }
    }

    return 0;
}

// 合并两个节点
void btr_merge_pages(BtreePage* left, BtreePage* right) {
    // 1. 迁移记录
    memcpy(left->rec_ptr + left->n_recs, right->rec_ptr,
           right->n_recs * sizeof(uint32_t));
    left->n_recs += right->n_recs;

    // 2. 更新链表指针
    left->header.next_page = right->header.next_page;
    if (right->header.next_page != 0) {
        BtreePage* next = btr_load_page(right->header.next_page);
        next->header.prev_page = left->header.page_no;
    }

    // 3. 释放右节点
    btr_free_page(right);

    // 4. 更新父节点（删除右节点的索引键）
    btr_remove_from_parent(right);
}

1.4.2 删除流程的时序图（节点合并）

sequenceDiagram
    participant Client as 客户端
    participant Btree as B+树
    participant Leaf1 as 叶子节点(P1)
    participant Leaf2 as 叶子节点(P2)
    participant Parent as 父节点(P0)

    Client->>Btree: 删除key=80（P1中）
    Btree->>Leaf1: 标记删除（P1剩余5条记录）
    Btree->>Leaf1: 检查节点（< MIN_RECS=10）
    Btree->>Leaf2: 检查前序节点P2（12条记录）
    Btree->>Leaf2: 合并P1到P2（5+12=17 ≤ 20）
    Btree->>Leaf2: 迁移P1记录到P2
    Btree->>Leaf1: 释放P1节点
    Btree->>Parent: 删除P1的索引键
    Parent->>Btree: 更新子节点指针
    Btree->>Client: 删除完成

1.4.3 删除操作的特殊场景处理

• 标记删除与物理删除：InnoDB 对删除记录先标记（deleted=1），再在后台线程（purge）中物理删除，避免频繁的节点合并。

• 非叶子节点删除：非叶子节点的记录删除后，需用其右子树的最小键填充（确保查询路径正确）。

• 树高降低：当根节点的子节点合并后仅剩一个时，根节点会降级为非叶子节点，树高减 1。

1.5 联合索引的底层实现与最左前缀原则

1.5.1 联合索引的键值结构

1.5.2 最左前缀原则的底层逻辑

• 匹配 WHERE a = 1 → 可用索引（最左前缀 a）。

• 匹配 WHERE a = 1 AND b = 2 → 可用索引（前缀 a, b）。

• 匹配 WHERE b = 2 → 不可用索引（缺失最左列 a）。

• 匹配 WHERE a = 1 AND c = 3 → 仅用 a 部分（c 不连续）。

1.5.3 联合索引查询的源码级匹配逻辑

// 检查查询条件是否匹配联合索引
bool index_matches_conditions(Index* idx, Query* query) {
    uint32_t matched = 0;
    // 遍历索引的列（按顺序）
    for (uint32_t i = 0; i < idx->n_columns; i++) {
        Column* col = idx->columns[i];
        // 检查是否有等值条件（=、IN）
        if (query->has_eq_condition(col)) {
            matched++;
        } else if (query->has_range_condition(col) && i == matched) {
            // 范围条件（>、<、BETWEEN）只能匹配到当前列
            matched++;
            break; // 后续列无法匹配
        } else {
            break; // 中间列缺失，终止匹配
        }
    }
    return matched > 0;
}

1.5.4 联合索引的查询时序图（匹配前缀）

sequenceDiagram
    participant Query as 查询(WHERE a=1 AND b=2)
    participant Index as 联合索引(a,b,c)
    participant Leaf as 叶子节点

    Query->>Index: 解析条件（a=1, b=2）
    Index->>Index: 匹配最左前缀（a,b）
    Index->>Leaf: 定位到(a=1, b=2)的记录范围
    Leaf->>Query: 返回符合条件的行ID

1.5.5 联合索引的查询时序图（前缀中断）

sequenceDiagram
    participant Query as 查询(WHERE a=1 AND c=3)
    participant Index as 联合索引(a,b,c)
    participant Leaf as 叶子节点

    Query->>Index: 解析条件（a=1, c=3）
    Index->>Index: 匹配最左前缀（仅a=1）
    Index->>Leaf: 定位到a=1的所有记录
    Leaf->>Query: 扫描过滤c=3的记录（无法用索引）

1.5.6 联合索引的设计原则（业务落地）

1. 高频查询优先：将查询中最频繁出现的列放在左侧（如用户中心系统中，user_id 作为最左列）。

2. 区分度高的列优先：区分度 = 不同值数量 / 总记录数，区分度高的列（如 order_id）放在左侧可快速缩小范围。

3. 覆盖查询需求：将查询的所有字段纳入联合索引（覆盖索引），避免回表。例如：

-- 查询：SELECT a,b,c FROM t WHERE a=1 AND b=2
-- 索引：(a,b,c) → 覆盖查询，无需回表

4. 避免重复索引：若已有 (a,b)，则 (a) 是冗余索引（因 (a,b) 的前缀 (a) 可替代）。

模块二：InnoDB 事务与锁机制的底层实现

2.1 事务的 ACID 特性与底层保障

2.1.1 原子性的实现：undo 日志

// undo 日志记录结构
struct UndoLog {
    uint64_t trx_id;         // 事务ID
    uint64_t roll_ptr;       // 指向更早版本的undo日志
    uint8_t log_type;        // 操作类型（INSERT/UPDATE/DELETE）
    uint8_t* old_data;       // 修改前的数据
};

// 事务回滚函数
void trx_rollback(Transaction* trx) {
    // 遍历事务的undo日志链
    UndoLog* log = trx->undo_log_head;
    while (log != NULL) {
        switch (log->log_type) {
            case INSERT:
                // 回滚插入：删除记录
                btr_delete(log->table, log->row_id);
                break;
            case UPDATE:
                // 回滚更新：恢复旧值
                btr_update(log->table, log->row_id, log->old_data);
                break;
            case DELETE:
                // 回滚删除：恢复记录
                btr_insert(log->table, log->row_id, log->old_data);
                break;
        }
        log = log->next;
    }
    // 释放undo日志
    trx_free_undo_log(trx);
}

sequenceDiagram
    participant Trx as 事务(T1)
    participant Undo as undo日志链
    participant Btree as 索引树

    Trx->>Trx: 触发回滚（ROLLBACK）
    Trx->>Undo: 读取第一条undo日志（UPDATE）
    Undo->>Btree: 恢复数据旧值
    Trx->>Undo: 读取第二条undo日志（INSERT）
    Undo->>Btree: 删除插入的记录
    Trx->>Undo: 释放所有undo日志
    Trx->>Trx: 事务结束

2.1.2 持久性的实现：redo 日志与双写缓冲

// redo 日志记录结构
struct RedoLog {
    uint64_t lsn;            // 日志序列号
    uint32_t table_id;       // 表ID
    uint64_t row_id;         // 行ID
    uint8_t* new_data;       // 修改后的数据
};

// 事务提交函数
void trx_commit(Transaction* trx) {
    // 1. 将redo日志写入日志缓冲
    log_buffer_write(trx->redo_logs);

    // 2. 刷新日志到磁盘（fsync）
    log_buffer_flush();

    // 3. 标记事务状态为提交
    trx->status = COMMITTED;

    // 4. 释放undo日志（或标记为可回收）
    trx_purge_undo_log(trx);
}

sequenceDiagram
    participant Trx as 事务(T1)
    participant RedoBuf as Redo日志缓冲
    participant Disk as 磁盘
    participant DoubleWrite as 双写缓冲

    Trx->>RedoBuf: 写入redo日志（LSN=100）
    Trx->>DoubleWrite: 写入修改后的页数据
    DoubleWrite->>Disk: 刷新双写缓冲到磁盘
    RedoBuf->>Disk: 刷新redo日志到磁盘（fsync）
    Trx->>Trx: 标记为已提交

2.2 MVCC：多版本并发控制的底层逻辑

2.2.1 行记录的隐藏字段

struct Row {
    uint64_t trx_id;         // 创建该版本的事务ID
    uint64_t roll_ptr;       // 指向undo日志的指针（用于回滚）
    uint64_t row_id;         // 自增行ID（无主键时使用）
};

• trx_id：生成该数据版本的事务ID（递增）。

• roll_ptr：指向 undo 日志的指针，可通过 undo 日志链获取历史版本。

2.2.2 Read View：事务的可见性判断依据

// Read View结构
struct ReadView {
    uint64_t low_limit_id;   // 最大事务ID（>此ID的事务不可见）
    uint64_t up_limit_id;    // 最小活跃事务ID（<此ID的事务可见）
    uint64_t* active_trx_ids;// 活跃事务ID列表（需特殊判断）
    uint64_t creator_trx_id; // 创建该视图的事务ID
};

// 可见性判断函数
bool row_visible(Row* row, ReadView* rv) {
    uint64_t trx_id = row->trx_id;

    // 1. 创建版本的事务已提交，且早于当前视图
    if (trx_id < rv->up_limit_id) {
        return true;
    }

    // 2. 创建版本的事务是当前事务
    if (trx_id == rv->creator_trx_id) {
        return true;
    }

    // 3. 创建版本的事务在视图创建后提交（不可见）
    if (trx_id >= rv->low_limit_id) {
        return false;
    }

    // 4. 检查是否为活跃事务（未提交）
    for (uint64_t active_id : rv->active_trx_ids) {
        if (trx_id == active_id) {
            return false; // 活跃事务的版本不可见
        }
    }

    return true; // 其他情况可见
}

2.2.3 不同隔离级别的 Read View 生成时机

• 读未提交（Read Uncommitted）：无 Read View，直接读取最新版本。

• 读已提交（Read Committed）：每次查询生成新的 Read View。

• 可重复读（Repeatable Read）：事务启动时生成一次 Read View，后续查询复用。

• 串行化（Serializable）：不使用 MVCC，通过锁实现完全隔离。

sequenceDiagram
    participant T1 as 事务T1（可重复读）
    participant RV as Read View
    participant Row as 数据行(version=1, trx_id=10)

    T1->>T1: 开始事务（START TRANSACTION）
    T1->>RV: 生成初始Read View（up_limit=10, low_limit=20）
    T1->>Row: 第一次查询（可见version=1）
    Note over T1,Row: 其他事务T2修改行数据（version=2, trx_id=20）
    T1->>Row: 第二次查询（仍用旧RV，可见version=1）
    T1->>T1: 提交事务

sequenceDiagram
    participant T1 as 事务T1（读已提交）
    participant RV1 as Read View 1
    participant RV2 as Read View 2
    participant Row as 数据行

    T1->>T1: 开始事务
    T1->>RV1: 第一次查询生成RV1（可见version=1）
    T1->>Row: 返回version=1
    Note over T1,Row: T2提交修改（version=2, trx_id=20）
    T1->>RV2: 第二次查询生成RV2（可见version=2）
    T1->>Row: 返回version=2
    T1->>T1: 提交事务

2.2.4 MVCC 读操作的全流程

// MVCC查询函数
ResultSet* mvcc_query(Transaction* trx, Table* table, Condition* cond) {
    ResultSet* result = new ResultSet();
    // 1. 获取事务的Read View
    ReadView* rv = trx->get_read_view();

    // 2. 扫描表数据（通过索引或全表）
    Index* idx = table->choose_index(cond);
    RecordCursor* cursor = idx->open_cursor(cond);

    // 3. 遍历记录并判断可见性
    while (Record* rec = cursor->next()) {
        Row* row = rec->row;
        if (row_visible(row, rv)) {
            // 4. 检查是否符合查询条件
            if (cond->matches(row)) {
                result->add(row);
            }
        } else {
            // 5. 回滚到可见版本
            Row* visible_row = rollback_to_visible(row, rv);
            if (visible_row && cond->matches(visible_row)) {
                result->add(visible_row);
            }
        }
    }
    return result;
}

// 回滚到可见版本
Row* rollback_to_visible(Row* row, ReadView* rv) {
    Row* current = row;
    while (true) {
        // 从undo日志获取前一版本
        UndoLog* undo = undo_log_get(current->roll_ptr);
        if (undo == NULL) break;

        current = undo->old_row;
        if (row_visible(current, rv)) {
            return current;
        }
    }
    return NULL; // 无可见版本
}

sequenceDiagram
    participant Query as 查询请求
    participant Trx as 事务(T1)
    participant RV as Read View
    participant Index as 索引树
    participant Undo as undo日志链

    Query->>Trx: 发起查询
    Trx->>RV: 获取Read View（T1的视图）
    Trx->>Index: 通过索引定位记录
    Index->>Trx: 返回最新版本行（trx_id=20）
    Trx->>RV: 判断可见性（20 >= low_limit=20 → 不可见）
    Trx->>Undo: 读取undo日志（roll_ptr指向旧版本）
    Undo->>Trx: 返回旧版本行（trx_id=10）
    Trx->>RV: 判断可见性（10 < up_limit=15 → 可见）
    Trx->>Query: 返回旧版本数据

2.3 锁机制：从行锁到 Next-Key 锁

2.3.1 锁的基本结构

// 锁结构定义
struct Lock {
    uint64_t lock_id;        // 锁ID
    uint64_t trx_id;         // 持有锁的事务ID
    uint32_t table_id;       // 表ID
    uint64_t space_id;       // 表空间ID
    uint64_t page_no;        // 页号
    uint64_t rec_no;         // 记录号（行锁）
    uint64_t lock_type;      // 锁类型（行锁/表锁）
    uint64_t lock_mode;      // 锁模式（S/X/IS/IX）
    uint64_t lock_space;     // 锁定范围（记录/间隙/Next-Key）
};

// 锁模式定义
enum LockMode {
    LOCK_S,    // 共享锁（读锁）
    LOCK_X,    // 排他锁（写锁）
    LOCK_IS,   // 意向共享锁
    LOCK_IX    // 意向排他锁
};

// 锁定范围定义
enum LockSpace {
    LOCK_REC,  // 记录锁（仅锁定某行）
    LOCK_GAP,  // 间隙锁（锁定两行之间的间隙）
    LOCK_NEXT  // Next-Key锁（记录+间隙）
};

2.3.2 记录锁（Record Lock）

// 获取记录锁函数
int lock_acquire_record(Transaction* trx, Table* table, Index* idx, const uint8_t* key) {
    // 1. 定位记录所在页和位置
    Page* page = idx->locate_page(key);
    uint32_t rec_no = page->find_record(key);

    // 2. 检查是否已有冲突锁
    if (lock_has_conflict(table->id, page->space_id, page->no, rec_no, trx->id)) {
        // 3. 存在冲突，进入等待队列
        trx->wait_for_lock(lock);
        return LOCK_WAIT;
    }

    // 4. 加锁
    Lock* lock = new Lock();
    lock->trx_id = trx->id;
    lock->table_id = table->id;
    lock->space_id = page->space_id;
    lock->page_no = page->no;
    lock->rec_no = rec_no;
    lock->lock_type = LOCK_REC;
    lock->lock_mode = LOCK_X; // 排他锁
    lock->add_to_lock_table();

    return LOCK_OK;
}

sequenceDiagram
    participant T1 as 事务T1
    participant LockMgr as 锁管理器
    participant Record as 记录(row_id=100)

    T1->>LockMgr: 请求记录锁（X锁，row_id=100）
    LockMgr->>Record: 检查当前锁状态（无锁）
    LockMgr->>T1: 加锁成功
    Note over T1,Record: T1修改记录

    participant T2 as 事务T2
    T2->>LockMgr: 请求记录锁（X锁，row_id=100）
    LockMgr->>Record: 检查当前锁状态（T1持有X锁）
    LockMgr->>T2: 进入等待队列
    Note over T2,T1: T2等待T1释放锁

2.3.3 间隙锁（Gap Lock）

// 间隙锁加锁函数
void lock_acquire_gap(Transaction* trx, Index* idx, const uint8_t* low, const uint8_t* high) {
    // 1. 定位间隙范围
    Gap gap = idx->find_gap(low, high);

    // 2. 创建间隙锁
    Lock* lock = new Lock();
    lock->trx_id = trx->id;
    lock->lock_type = LOCK_GAP;
    lock->lock_mode = LOCK_X;
    lock->gap_low = low;
    lock->gap_high = high;
    lock->add_to_lock_table();
}

sequenceDiagram
    participant T1 as 事务T1
    participant LockMgr as 锁管理器
    participant Index as 索引(id)

    T1->>LockMgr: 请求间隙锁（X锁，id BETWEEN 10 AND 20）
    LockMgr->>Index: 定位间隙（10,20）
    LockMgr->>T1: 加锁成功（锁定(10,20)间隙）

    participant T2 as 事务T2
    T2->>LockMgr: 尝试插入id=15
    LockMgr->>Index: 检查插入位置（在(10,20)间隙内）
    LockMgr->>T2: 间隙锁冲突，进入等待

2.3.4 Next-Key 锁：记录锁 + 间隙锁

// Next-Key锁加锁函数
void lock_acquire_next_key(Transaction* trx, Index* idx, const uint8_t* key) {
    // 1. 对记录加记录锁
    lock_acquire_record(trx, idx->table, idx, key);

    // 2. 对记录前的间隙加间隙锁
    uint8_t* prev_key = idx->find_previous_key(key);
    lock_acquire_gap(trx, idx, prev_key, key);
}

sequenceDiagram
    participant T1 as 事务T1
    participant LockMgr as 锁管理器
    participant Index as 索引(id:10,20,30)

    T1->>LockMgr: 请求Next-Key锁（X锁，id=20）
    LockMgr->>Index: 对id=20加记录锁
    LockMgr->>Index: 对(10,20)间隙加间隙锁
    LockMgr->>T1: 加锁成功（锁定(10,20]）

    participant T2 as 事务T2
    T2->>LockMgr: 尝试更新id=20 → 记录锁冲突
    T2->>LockMgr: 尝试插入id=15 → 间隙锁冲突
    T2->>LockMgr: 尝试插入id=25 → 不冲突（在(20,30)间隙）

2.4 事务隔离级别与锁的关联

sequenceDiagram
    participant T1 as 事务T1（可重复读）
    participant LockMgr as 锁管理器
    participant Index as 索引(id)

    T1->>LockMgr: 执行SELECT * FROM t WHERE id < 10 FOR UPDATE
    LockMgr->>Index: 加Next-Key锁（锁定(-∞,10]）
    T1->>T1: 读取到id=5,8的记录

    participant T2 as 事务T2
    T2->>LockMgr: 尝试插入id=7
    LockMgr->>Index: 插入位置在(-∞,10] → 锁冲突
    LockMgr->>T2: 进入等待队列
    Note over T2,T1: T2无法插入，防止幻读

2.5 死锁检测与处理

2.5.1 死锁检测算法（等待图）

// 等待图节点（事务）
struct WaitNode {
    uint64_t trx_id;         // 事务ID
    List<uint64_t> waits_for; // 等待的事务ID列表
};

// 死锁检测函数
bool detect_deadlock(LockTable* lock_table) {
    // 1. 构建等待图
    List<WaitNode> nodes = build_wait_graph(lock_table);

    // 2. 检测环（深度优先搜索）
    for (WaitNode& node : nodes) {
        if (has_cycle(node, new Set<uint64_t>())) {
            return true;
        }
    }
    return false;
}

// 检测环（DFS）
bool has_cycle(WaitNode& node, Set<uint64_t>* visited) {
    if (visited->contains(node.trx_id)) {
        return true; // 发现环
    }
    visited->add(node.trx_id);
    for (uint64_t wait_for : node.waits_for) {
        WaitNode* next = find_node(wait_for);
        if (has_cycle(*next, visited)) {
            return true;
        }
    }
    visited->remove(node.trx_id);
    return false;
}

sequenceDiagram
    participant T1 as 事务T1
    participant T2 as 事务T2
    participant LockMgr as 锁管理器

    T1->>LockMgr: 获取锁A（X锁）
    T2->>LockMgr: 获取锁B（X锁）
    T1->>LockMgr: 请求锁B → 等待T2
    T2->>LockMgr: 请求锁A → 等待T1
    LockMgr->>LockMgr: 构建等待图（T1→T2→T1）
    LockMgr->>LockMgr: 检测到死锁
    LockMgr->>LockMgr: 选择代价小的T2回滚
    T2->>LockMgr: 释放锁B
    LockMgr->>T1: 获得锁B，继续执行

2.5.2 实际业务中的死锁预防策略

1. 统一锁顺序：所有事务按相同顺序获取锁（如先锁A后锁B）。

2. 缩小事务范围：减少事务持有锁的时间（如拆分大事务为小事务）。

3. 使用低隔离级别：如读已提交隔离级别可减少间隙锁，降低死锁概率。

4. 设置锁等待超时：通过 innodb_lock_wait_timeout 设置超时时间（默认50秒），避免无限等待。

模块三：慢查询优化的底层逻辑与实践指南

3.1 查询优化器：从 SQL 到执行计划的转化器

3.1.1 SQL 执行的全链路流程

1. 词法与语法解析：将 SQL 字符串转化为抽象语法树（AST），检查语法正确性（如关键字是否正确、括号是否匹配）。

2. 语义分析：验证表、列是否存在，处理别名，检查权限等。

3. 生成执行计划：优化器根据表统计信息（行数、索引区分度等），生成可能的执行计划（如全表扫描、索引扫描、JOIN 顺序等）。

4. 代价评估：计算每个执行计划的代价（IO 代价 + CPU 代价），选择代价最小的计划。

5. 执行计划：执行器按照最优计划调用存储引擎接口（如 InnoDB 的 ha_innodb::index_read）获取数据。

sequenceDiagram
    participant Client as 客户端
    participant Parser as 解析器
    participant Optimizer as 优化器
    participant Executor as 执行器
    participant InnoDB as 存储引擎

    Client->>Parser: 输入SQL（SELECT * FROM t WHERE id=1）
    Parser->>Parser: 词法分析（识别关键字、表名、列名）
    Parser->>Parser: 语法分析（生成AST）
    Parser->>Optimizer: 传递AST
    Optimizer->>Optimizer: 语义分析（验证表/列存在性）
    Optimizer->>Optimizer: 生成候选执行计划（全表扫描/索引扫描）
    Optimizer->>Optimizer: 代价计算（索引扫描代价更低）
    Optimizer->>Executor: 传递最优执行计划（使用主键索引）
    Executor->>InnoDB: 调用索引读取接口
    InnoDB->>Executor: 返回数据
    Executor->>Client: 返回查询结果

3.1.2 执行计划的生成与代价模型

• IO 代价：读取数据页的成本（磁盘 IO 远高于内存访问，是主要代价）。

• CPU 代价：解析记录、过滤条件、排序等计算成本。

// 执行计划代价结构
struct PlanCost {
    double io_cost;   // IO代价（读取数据页的成本）
    double cpu_cost;  // CPU代价（计算成本）
    double total() { return io_cost + cpu_cost; } // 总代价
};

// 计算全表扫描代价
PlanCost calculate_full_scan_cost(Table* table, Query* query) {
    PlanCost cost;
    // 1. IO代价：表的总页数 × 每页IO成本
    cost.io_cost = table->n_pages * IO_COST_PER_PAGE;

    // 2. CPU代价：总记录数 × 每条记录的过滤成本
    cost.cpu_cost = table->n_rows * CPU_COST_PER_ROW;

    return cost;
}

// 计算索引扫描代价
PlanCost calculate_index_scan_cost(Index* idx, Query* query) {
    PlanCost cost;
    // 1. 估算索引扫描的记录数（基于索引统计信息）
    uint64_t n_index_rows = estimate_rows_using_index(idx, query);

    // 2. IO代价：索引页数量 + 回表数据页数量
    cost.io_cost = (idx->n_pages + n_index_rows * 0.1) * IO_COST_PER_PAGE;
    // （注：0.1是平均回表比例，根据索引选择性估算）

    // 3. CPU代价：索引记录过滤 + 回表数据过滤
    cost.cpu_cost = n_index_rows * CPU_COST_PER_INDEX_ROW
                  + n_index_rows * 0.1 * CPU_COST_PER_DATA_ROW;

    return cost;
}

3.1.3 优化器如何选择执行计划？

1. 全表扫描 t1，过滤 t1.a=1，再嵌套循环 JOIN t2（用 t2.t1_id 索引）。

2. 索引扫描 t1（用 t1.a 索引），过滤 t1.a=1，再哈希 JOIN t2。

3. 全表扫描 t2，过滤后哈希 JOIN t1（较少见，取决于表大小）。

sequenceDiagram
    participant Optimizer as 优化器
    participant Stats as 统计信息
    participant Plan1 as 计划1（全表扫描t1 + 索引JOIN t2）
    participant Plan2 as 计划2（索引扫描t1 + 哈希JOIN t2）

    Optimizer->>Stats: 获取t1/t2的行数、索引信息
    Optimizer->>Plan1: 计算代价（总代价=1000）
    Optimizer->>Plan2: 计算代价（总代价=500）
    Optimizer->>Optimizer: 选择代价更小的Plan2

3.2 统计信息：优化器的「眼睛」

3.2.1 统计信息的类型与收集方式

// 收集表统计信息
void update_table_stats(Table* table) {
    // 1. 采样计算行数（随机选8个页）
    uint64_t sampled_rows = 0;
    for (int i = 0; i < 8; i++) {
        Page* page = table->random_page();
        sampled_rows += page->n_recs;
    }
    // 估算总页数 × 平均每页行数
    table->table_rows = (table->n_pages * sampled_rows) / 8;

    // 2. 更新平均行长度
    table->avg_row_length = table->data_size / table->table_rows;
}

// 收集索引统计信息
void update_index_stats(Index* idx) {
    // 1. 采样计算索引基数（不同值的数量）
    uint64_t sampled_distinct = 0;
    for (int i = 0; i < 8; i++) {
        Page* page = idx->random_page();
        sampled_distinct += count_distinct_values(page);
    }
    // 估算总基数
    idx->cardinality = (idx->n_pages * sampled_distinct) / 8;
}

3.2.2 统计信息不准确导致的慢查询

• 实际表行数 100 万，但统计信息显示 1 万 → 优化器可能选择嵌套循环 JOIN（适合小表），而非哈希 JOIN（适合大表）。

• 索引实际区分度很高（基数 100 万），但统计信息显示基数 100 → 优化器可能认为索引价值低，选择全表扫描。

1. 手动更新统计信息：ANALYZE TABLE t;（会加读锁，建议低峰期执行）。

2. 调整采样页数量：innodb_stats_persistent_sample_pages = 64（增大采样量，提高准确性）。

3.3 基于代价的索引选择：为什么优化器不选「看起来更好」的索引？

3.3.1 索引代价的计算逻辑

• 过滤记录数少：索引的区分度高（如 WHERE id = 1），过滤后只剩少量记录，回表成本低 → 索引代价低。

• 过滤记录数多：索引的区分度低（如 WHERE status = 1，status 只有 2 个值），过滤后仍有大量记录，回表成本高 → 索引代价可能高于全表扫描。

// 评估索引是否值得使用
bool is_index_useful(Index* idx, Query* query) {
    // 1. 估算通过索引过滤后的记录数
    uint64_t filtered_rows = estimate_filtered_rows(idx, query);

    // 2. 计算索引扫描 + 回表的总代价
    PlanCost index_cost = calculate_index_scan_cost(idx, query);

    // 3. 计算全表扫描的代价
    PlanCost full_cost = calculate_full_scan_cost(idx->table, query);

    // 4. 索引代价低于全表扫描代价的1/3时，认为值得使用
    return index_cost.total() < full_cost.total() * 0.33;
}

3.3.2 索引不被使用的典型场景

1. 索引过滤后记录仍过多
例：SELECT * FROM orders WHERE status = 1（status 只有 2 个值，50% 记录符合条件）。
原因：索引过滤后仍有 50 万条记录，回表需访问 50 万行数据，代价高于全表扫描（1 万页，每页 100 行）。

2. 索引列参与计算或函数
例：SELECT * FROM t WHERE SUBSTR(name, 1, 3) = 'abc'。
原因：索引存储的是原始值，函数计算后的值无法通过索引定位 → 优化器无法使用索引。

3. 统计信息过时
例：表实际行数 100 万，但统计信息显示 1 万，索引过滤后估算 1000 行，实际 10 万行 → 优化器误判索引代价低。

3.3.3 如何让优化器使用目标索引？

1. 优化过滤条件：使索引过滤后的记录数减少（如增加更多过滤条件）。
例：SELECT * FROM orders WHERE status = 1 AND create_time > '2023-01-01'（结合时间过滤，减少记录数）。

2. 避免索引列计算：将函数计算移到等号右侧。
例：WHERE name LIKE 'abc%'（可用索引）而非 SUBSTR(name, 1, 3) = 'abc'（不可用）。

3. 强制使用索引：SELECT * FROM t FORCE INDEX (idx_a) WHERE a = 1;（谨慎使用，可能因数据变化导致性能反降）。

3.4 慢查询优化实战：从案例看底层原理

3.4.1 案例一：JOIN 语句优化——从「30 秒」到「300 毫秒」

-- 慢查询：30秒
SELECT o.order_id, u.user_name
FROM orders o
JOIN users u ON o.user_id = u.user_id
WHERE o.status = 1 AND o.create_time > '2023-01-01';

• orders 表的 status 和 create_time 无联合索引，过滤条件 status=1 AND create_time>'2023-01-01' 无法有效过滤，导致全表扫描。

• JOIN 时以 orders 为驱动表（大表），users 为被驱动表，嵌套循环次数过多（100 万 × 单条查询）。

1. 为 orders 表添加联合索引：idx_status_time_user(status, create_time, user_id)（覆盖 WHERE 条件和 JOIN 字段，避免回表）。

2. 优化器会选择 orders 为驱动表（过滤后仅 1 万行），users 为被驱动表，JOIN 次数降至 1 万次。

sequenceDiagram
    participant OldPlan as 原计划（全表扫描）
    participant NewPlan as 新计划（索引扫描）
    participant Orders as orders表
    participant Users as users表

    OldPlan->>Orders: 全表扫描（100万行）
    Orders->>Users: 每行JOIN users（100万次）
    Users->>OldPlan: 返回结果（耗时30秒）

    NewPlan->>Orders: 索引扫描（idx_status_time_user）
    Orders->>Orders: 过滤后1万行（无需回表）
    Orders->>Users: 每行JOIN users（1万次）
    Users->>NewPlan: 返回结果（耗时300ms）

3.4.2 案例二：排序优化——filesort 导致的慢查询

-- 慢查询：5秒
SELECT id, name, price FROM products
WHERE category_id = 10
ORDER BY sales DESC
LIMIT 10;

• category_id 有索引，但排序字段 sales 不在索引中 → 优化器先通过索引过滤 category_id=10（1 万行），再将 1 万行加载到内存排序（filesort），排序成本高。

• 索引中 category_id=10 的记录已按 sales 降序排列，无需额外排序 → Extra: Using index; Using where（无 filesort）。

sequenceDiagram
    participant Old as 原查询（filesort）
    participant New as 新查询（索引排序）
    participant Index as 索引idx_category_sales

    Old->>Index: 用category_id索引过滤（1万行）
    Old->>Old: 加载1万行到内存排序（filesort）
    Old->>Old: 取前10行（耗时5秒）

    New->>Index: 用联合索引过滤+排序（category_id=10的记录已按sales降序）
    Index->>New: 直接取前10行（无需排序，耗时50ms）

3.4.3 案例三：子查询优化——从「嵌套查询」到「JOIN」

-- 慢查询：8秒
SELECT * FROM orders
WHERE user_id IN (
    SELECT user_id FROM orders
    WHERE product_id = 100 AND create_time > '2023-01-01'
)
AND create_time > '2023-03-01';

• MySQL 对某些子查询优化不佳，会将子查询转化为相关子查询（外层每一行触发一次子查询）。

SELECT o.* FROM orders o
JOIN (
    SELECT DISTINCT user_id FROM orders
    WHERE product_id = 100 AND create_time > '2023-01-01'
) u ON o.user_id = u.user_id
WHERE o.create_time > '2023-03-01';

3.5 慢查询优化的通用步骤

1. 捕获慢查询：开启慢查询日志（slow_query_log = 1，long_query_time = 1），定位执行时间超过 1 秒的 SQL。

2. 分析执行计划：用 EXPLAIN 或 EXPLAIN ANALYZE（MySQL 8.0+）查看执行计划，重点关注：
• type：访问类型（ALL 全表扫描、ref 索引匹配、range 范围扫描、const 常量匹配）。
• key：实际使用的索引（NULL 表示未用索引）。
• rows：估算扫描行数（值越大，代价越高）。
• Extra：额外信息（Using filesort 排序、Using temporary 临时表、Using index 覆盖索引等）。

3. 优化索引：根据最左前缀原则、覆盖索引需求，调整或新增索引。

4. 改写 SQL：避免子查询、SELECT *、索引列计算等，优先使用 JOIN 替代子查询。

5. 验证效果：对比优化前后的执行时间和执行计划，确保优化有效。

模块四：日常开发中的数据库设计与避坑指南

4.1 表结构设计：从「能用」到「高效」

4.1.1 数据类型选择：更小、更简单

4.1.2 主键设计：自增主键 vs 业务主键

• 优点：插入性能高（始终在叶子节点末尾插入，无节点分裂）；索引结构紧凑（主键索引即数据本身，无回表）。

• 适用场景：大多数业务表（订单表、用户表等）。

• 优点：天然唯一（如身份证号、订单号），无需额外维护自增 ID。

• 缺点：若业务主键是字符串（如 UUID），插入时会导致 B+ 树节点分裂（UUID 无序），性能下降；长度长（如 36 字节 UUID），索引占用空间大。

• 适用场景：需跨系统唯一标识的场景（如分布式 ID），建议用「雪花算法」生成有序长整型 ID。

4.1.3 分表分库：突破单表性能瓶颈

1. 水平分表：按行拆分，将大表拆分为多个结构相同的小表。
• 分表键选择：如订单表按 user_id % 10 分 10 表（用户维度查询友好），或按 create_time 分表（时间范围查询友好）。
• 实现方式：应用层分表（如 Sharding-JDBC）或中间件分表（如 MyCat）。

2. 垂直分表：按列拆分，将大宽表拆分为多个小表（适合字段多、冷热数据分离的场景）。
• 例：用户表拆分为 user_base（基本信息，高频访问）和 user_extra（详细信息，低频访问）。

4.2 SQL 编写规范：避免「隐形性能杀手」

4.2.1 索引相关规范

1. 避免索引失效的写法：
• 不在索引列上做计算：WHERE SUBSTR(name, 1, 3) = 'abc' → 改为 WHERE name LIKE 'abc%'（可用前缀索引）。
• 不使用 NOT IN != IS NOT NULL：可能导致全表扫描，改为 IN 或范围查询。
• 避免 OR 连接不同索引列：WHERE a = 1 OR b = 2（若 a 和 b 分别有索引，优化器可能不用）→ 改为 UNION。

2. 合理使用 LIMIT：
• 避免 LIMIT 100000, 10（需扫描 100010 行，丢弃前 100000 行）→ 用「书签分页」：LIMIT 10 WHERE id > 100000（需主键有序）。

4.2.2 事务与锁相关规范

1. 控制事务大小：
• 避免长事务：长事务会持有锁时间长，增加死锁风险，且会导致 undo 日志膨胀（MVCC 版本管理需要）。
• 例：批量插入 10 万条数据 → 拆分多个事务（每 1000 条一个事务）。

2. 避免循环中操作数据库：

// 反例：1000次单条插入
for (User user : users) {
    jdbcTemplate.update("INSERT INTO t VALUES(?)", user.getId());
}
// 优化：批量插入（1次SQL）
jdbcTemplate.batchUpdate("INSERT INTO t VALUES(?)", users);

4.3 常见问题处理方案

4.3.1 死锁处理

LATEST DETECTED DEADLOCK
------------------------
TRANSACTION 12345, ACTIVE 10 sec
10 lock struct(s), heap size 1128, 5 row lock(s)
MySQL thread id 10, OS thread handle 1406, query id 100 localhost root updating
UPDATE orders SET status=2 WHERE id=10

TRANSACTION 12346, ACTIVE 8 sec
10 lock struct(s), heap size 1128, 5 row lock(s)
MySQL thread id 11, OS thread handle 1407, query id 101 localhost root updating
UPDATE orders SET status=2 WHERE id=20

1. 分析死锁日志，确定两个事务的 SQL 和加锁顺序。

2. 统一加锁顺序：确保所有事务按相同顺序获取锁（如先锁 ID 小的记录）。

3. 缩小事务范围：减少事务持有锁的时间。

4.3.2 连接池配置：避免「连接耗尽」

• 连接池最大连接数：maxPoolSize = CPU核心数 × 2 + 有效磁盘数（通常 10-50 为宜，不宜过大）。

• 最小空闲连接数：minIdle = 5（保持少量空闲连接，避免频繁创建）。

• 连接超时：connectionTimeout = 30000（30 秒，避免长时间等待）。

• 验证查询：validationQuery = SELECT 1（借用连接时验证有效性）。

总结：从底层原理到工程实践的思维跃迁

1. B+ 树索引：不仅是「快速查找工具」，其有序性、链表结构、联合索引的最左前缀原则，决定了查询语句的设计方式（如范围查询、排序的优化）。

2. 事务与锁：ACID 特性的背后是 undo/redo 日志、MVCC、Next-Key 锁的协同工作，高并发场景下的一致性问题（如幻读、死锁）需结合隔离级别和锁策略解决。

3. 查询优化器：不是「万能的」，其决策依赖于统计信息和代价模型，开发者需通过合理的索引设计、SQL 改写，引导优化器选择最优执行计划。

4. 工程实践：优秀的数据库设计是「预防性能问题」的关键，表结构、SQL 写法、连接池配置等细节，决定了系统在高并发、大数据量下的稳定性。

参考文献

1. 《高性能 MySQL》（第 3 版）：深入解析 MySQL 索引、事务、锁机制的经典著作。

2. MySQL 官方文档：InnoDB 存储引擎、查询优化器。

3. InnoDB 源码：github.com/mysql/mysql-server（存储引擎核心逻辑在 storage/innobase 目录）。

4. 《数据库系统概念》（第 7 版）：讲解事务、锁、并发控制的理论基础。