vault backup: 2026-08-08 19:01:04

2026-08-08 19:01:04 +08:00
parent 1a4a83bc67
commit e2975eb86b
46 changed files with 9370 additions and 0 deletions
@@ -0,0 +1,163 @@
+---
+tags: [mysql, bplus-tree, clustered-index, secondary-index, page-split]
+create time: 2026-08-08 18:00
+update time: 2026-08-08 18:00
+---
+
+# B+树索引原理
+
+## 概述
+
+InnoDB 存储引擎的默认索引结构是 B+树（Balanced Plus Tree），它是 MySQL 实现高效范围查询和精确匹配的核心数据结构。理解 B+树的设计哲学——为什么选它而不是 B 树或红黑树——是掌握 MySQL 查询性能底层逻辑的第一步。
+
+## 核心原理
+
+### B 树与 B+树的本质区别
+
+B+树并非独立发明，而是 B 树的演化版本。两者的核心差异在于**数据存放位置**：
+
+- **B 树**：每个节点都存储键值和对应数据记录
+- **B+树**：非叶子节点只存键（不存数据），所有数据统一在叶子节点
+
+这意味着同样大小的页（通常 16KB），B+树的非叶子节点可以容纳更多键，从而降低树的高度。
+
+| 对比维度 | B 树 | B+树 |
+|---------|------|------|
+| 数据存储 | 所有节点均存数据 | 仅叶子节点存数据 |
+| 非叶子节点作用 | 既做路由又存数据 | 纯路由，无数据负担 |
+| 叶子节点连接 | 无连接 | 双向链表串联 |
+| 范围查询 | 需中序遍历，效率低 | 直接遍历叶子链表，一步到位 |
+| 磁盘 IO 次数 | 较高 | 更低（同等数据量下树更矮） |
+| 查询稳定性 | 不同路径长度可能不同 | 所有查询路径等长 |
+
+```mermaid
+graph TD
+    subgraph "B 树 - 每个节点含数据"
+        B_Root["根节点\nK1 D1"] -->|"≤K1"| B_L["左子节点\nK2 D2"]
+        B_Root -->|"K1<K≤K2"| B_M["中间节点\nK3 D3"]
+        B_Root -->|">K2"| B_R["右子节点\nK4 D4"]
+    end
+
+    subgraph "B+树 - 仅叶子节点含数据"
+        N_Root["根节点\nK2"] -->|"≤K2"| N_Inter["内节点\nK1 K3"]
+        N_Root -->|">K2"| N_Right["内节点\nK4 K5"]
+        N_Inter -->|"≤K1"| L1["叶子 K1→D1"]
+        N_Inter -->|"K1~K3"| L2["叶子 K2→D2"]
+        N_Inter -->|"K3~K4"| L3["叶子 K3→D3"]
+        N_Right -->|"K4~K5"| L4["叶子 K4→D4"]
+        N_Right -->|">K5"| L5["叶子 K5→D5"]
+        L1 -.->|"双向链表"| L2
+        L2 -.-> L3
+        L3 -.-> L4
+        L4 -.-> L5
+    end
+```
+
+> [!NOTE] 关键直觉
+> 树的高度每降低一层，意味着一次查询减少一次磁盘 IO。B+树通过让内节点只存索引而不存数据，让单个页能放下更多键，从而将 1 亿行数据的树高控制在 3~4 层，而 B 树可能需要 4~5 层。
+
+### 页分裂与页合并机制
+
+B+树的每个节点对应 InnoDB 的一个数据页（Page），默认大小为 16KB。当数据插入导致页满时，触发再平衡操作。
+
+**页分裂规则**：
+- 原页保留最左侧约一半的记录，新页获得剩余记录
+- 父节点增加一个分割键（split key），指向新页
+- 如果父节点也满了，递归向上分裂，直到找到不满的父节点或到达根节点
+- 根节点分裂时，树的高度 +1
+
+**页合并规则**：
+- 删除操作使页填充率低于一定阈值（默认约 50%，可通过 `innodb_fill_factor` 调整）时，尝试与相邻页合并
+- 合并方向优先选择右侧页；若右侧页也无法合并，则尝试左侧
+- 合并后，父节点中的分割键被移除
+
+> [!WARNING] 常见误区
+> 很多人认为页分裂发生在"页使用率达到 100%"时，实际上 InnoDB 在预分页阶段就会考虑空间利用率。InnoDB 采用"首次分裂占 7/8，后续平分"的策略来预留碎片空间，避免频繁分裂。
+
+### 聚簇索引与非聚簇索引
+
+这是 InnoDB 索引体系中最核心的概念之一。
+
+**聚簇索引（Clustered Index）**：
+- InnoDB 的数据文件和索引文件是同一份——这就是"聚簇"的含义
+- 主键索引就是聚簇索引，叶子节点存储整行完整数据
+- 一张表有且仅有**一个**聚簇索引
+
+**二级索引（Secondary Index / Non-Clustered Index）**：
+- 除主键之外的所有索引都是二级索引
+- 叶子节点存储的是**索引列的值 + 主键值**，而非完整行数据
+- 通过二级索引查到主键后，再用主键回表查询完整数据
+
+```mermaid
+graph LR
+    subgraph "聚簇索引（主键索引）叶子节点"
+        CI1["PK=1 → 完整行"]
+        CI2["PK=5 → 完整行"]
+        CI3["PK=10 → 完整行"]
+    end
+
+    subgraph "二级索引（name字段）叶子节点"
+        SI1["name='Alice' → PK=1"]
+        SI2["name='Bob' → PK=5"]
+        SI3["name='Charlie' → PK=10"]
+    end
+
+    SI1 --> CI1
+    SI2 --> CI2
+    SI3 --> CI3
+```
+
+> [!TIP] 面试常考点
+> 问："为什么主键要尽量短？" 答案：因为所有二级索引叶子节点都存储了主键值，主键越长，二级索引越大，内存中能缓存的索引页数越少，命中率越低。这也是推荐使用自增 BIGINT 而非 UUID 作为主键的原因之一。
+
+### 覆盖索引的起点
+
+B+树的二级索引结构天然支持"覆盖索引"优化——当查询的列全部存在于某个二级索引中时，无需回表即可返回结果。这一话题将在 [[覆盖索引与回表优化]] 中详细展开。
+
+## 代码示例
+
+以下 SQL 演示如何通过执行计划观察聚簇索引与二级索引的使用差异：
+
+```sql
+-- 建表并建立索引
+CREATE TABLE users (
+    id BIGINT AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(64) NOT NULL,
+    email VARCHAR(128) UNIQUE,
+    age INT NOT NULL,
+    INDEX idx_name_age (name, age)
+);
+
+-- 使用覆盖索引：不需要回表
+EXPLAIN SELECT name FROM users WHERE name = 'Alice';
+-- Extra: Using index （直接从 idx_name_age 二级索引获取 name）
+
+-- 需要回表：二级索引查不到所需列
+EXPLAIN SELECT * FROM users WHERE name = 'Alice';
+-- Extra: Using where（先走 idx_name_age 拿到 id，再回聚簇索引取全行）
+```
+
+## 实践场景
+
+**场景一：选型主键**
+- 优先使用自增 BIGINT 或 BIGINT UNSIGNED 作为主键，保持顺序写入减少页分裂
+- 绝对避免用 UUID 或随机字符串作为主键——乱序插入会导致频繁的页分裂和碎片
+
+**场景二：联合索引的顺序设计**
+- 区分度高的列放前面（如 user_id 优于 status）
+- 等值查询列在前，范围查询列在后（范围查询会中断最左前缀匹配）
+
+**场景三：监控页分裂**
+```sql
+-- 查看表中页的使用情况
+SELECT table_name, data_length, index_length
+FROM information_schema.tables
+WHERE engine = 'InnoDB';
+
+-- 填充率低说明页分裂频繁，考虑 OPTIMIZE TABLE
+```
+
+## 扩展阅读
+- [[覆盖索引与回表优化]]
+- [[Explain 执行计划解读]]
+- [[ACID 与 MVCC 机制]]
@@ -0,0 +1,172 @@
+---
+tags: [mysql, explain, execution-plan, index-pushdown, filesort]
+create time: 2026-08-08 18:00
+update time: 2026-08-08 18:00
+---
+
+# Explain 执行计划解读
+
+## 概述
+
+`EXPLAIN` 是 MySQL 提供的最重要的性能诊断工具。它在 SQL 真正执行之前，模拟优化器生成 SQL 的执行计划，揭示查询是如何使用索引、如何连接表、是否有临时表和文件排序等关键信息。掌握 EXPLAIN 输出各字段的含义，是将经验式调优转化为精准打击的前提。
+
+## 核心原理
+
+### 执行计划各字段详解
+
+#### type 字段 —— 访问类型（性能由好到差）
+
+type 描述了 MySQL 如何访问表中的数据，是评估查询质量的首要指标。
+
+| type | 名称 | 含义 | 性能 |
+|------|------|------|------|
+| `system` | 系统表 | 表仅有一行（system 表），常数级读取 | ★★★★★ |
+| `const` | 常量 | 最多匹配一行，通过主键/唯一索引一次性定位 | ★★★★★ |
+| `eq_ref` | 等值引用 | 前一个表的每一行，当前表通过唯一索引匹配一行 | ★★★★☆ |
+| `ref` | 引用 | 通过非唯一索引或主键的前缀匹配多行 | ★★★☆☆ |
+| `range` | 范围 | 索引范围扫描，如 BETWEEN、IN、>、< | ★★☆☆☆ |
+| `index` | 全索引扫描 | 遍历整个索引树，不走表数据 | ★★☆☆☆ |
+| `ALL` | 全表扫描 | 逐行扫描表数据，未使用任何索引 | ☆☆☆☆☆ |
+
+```mermaid
+graph LR
+    A["system"] -->|"最优"| B["const"]
+    B --> C["eq_ref"]
+    C --> D["ref"]
+    D --> E["range"]
+    E --> F["index"]
+    F --> G["ALL"]
+    G -->|"最差"| H["需要优化"]
+
+    style A fill:#90ee90
+    style B fill:#90ee90
+    style C fill:#90ee90
+    style D fill:#ffeb99
+    style E fill:#ffeb99
+    style F fill:#ffcc99
+    style G fill:#ff9999
+    style H fill:#ff6666
+```
+
+> [!TIP] 面试常考点
+> 为什么 index 比 ALL 好？`index` 虽然是全表扫描级别，但它只扫描索引树（通常为有序排列，可利用顺序 IO），而 `ALL` 需要扫描数据行（随机 IO）。所以 `index < ALL`。
+
+#### select_type 字段 —— 查询类型
+
+| select_type | 含义 |
+|-------------|------|
+| `SIMPLE` | 简单查询，不包含子查询或 UNION |
+| `PRIMARY` | 最外层查询（配合 SUBQUERY/UNION 等出现） |
+| `SUBQUERY` | 子查询中的 SELECT（非 FROM 子句中） |
+| `DERIVED` | 派生表（FROM 子句中的子查询） |
+| `UNION` | UNION 中的第二个及以后的 SELECT |
+| `UNION RESULT` | UNION 的结果集 |
+
+```sql
+-- 示例：复杂查询的 select_type
+SELECT * FROM orders o
+WHERE o.user_id IN (
+    SELECT u.id FROM users u WHERE u.status = 1
+)
+UNION
+SELECT * FROM orders_archive WHERE archived = 1;
+-- 输出行的 select_type 依次为：PRIMARY / SUBQUERY / UNION / UNION_RESULT
+```
+
+#### possible_keys vs key vs key_len
+
+- **possible_keys**：优化器认为可能用到的索引列表（只是"候选"，不代表最终会选用）
+- **key**：实际选择的索引
+- **key_len**：使用的索引长度（字节数），反映索引列参与的程度
+
+```sql
+-- 复合索引 (name VARCHAR(64), age INT)
+-- utf8mb4 每个字符 4 字节，name 的 key_len = 64 * 4 = 256 字节
+-- 加上变长标记 1 字节 + NULL 标记 1 字节 = 258
+-- 如果 key_len = 258，说明用了 name 列
+-- 如果 key_len = 262 (= 258 + 4)，说明同时用了 name 和 age
+
+SELECT * FROM users WHERE name = 'Alice' AND age = 25;
+-- key: idx_name_age, key_len: 262 → 两个列都用上了
+```
+
+#### rows × filtered —— 行数估算
+
+- **rows**：优化器估算的需要扫描的行数（越小越好）
+- **filtered**：按表条件筛选后，留存行的百分比（0~100）
+- **rows × filtered%** ≈ 实际需要处理的行数
+
+> [!WARNING] 估算偏差
+> rows 和 filtered 是统计采样估算值，并非精确计数。如果表的统计信息过期，可能导致严重偏差。执行 `ANALYZE TABLE t;` 可以更新统计信息。
+
+### Extra 常见值解析
+
+| Extra 值 | 含义 | 建议 |
+|----------|------|------|
+| `Using where` | 存储引擎返回数据后，Server 层再做 WHERE 过滤 | 正常，但如果没走索引说明需要加索引 |
+| `Using index` | 覆盖索引，无需回表 | 最好的情况 |
+| `Using temporary` | 使用了临时表解决查询 | 通常出现在 GROUP BY 或 DISTINCT，需要优化 |
+| `Using filesort` | 需要额外排序，无法利用索引顺序 | 考虑加索引消除排序 |
+| `Using index condition` | 索引下推（ICP），在存储引擎层过滤 | 好消息，说明 MySQL 自动优化了 |
+| `Using sort_union()` / `Using union()` | 使用了多个索引合并后再排序 | 考虑改造成单索引 |
+| `Impossible where` | WHERE 条件永远不成立 | 检查 SQL 逻辑 |
+| `Select tables optimized away` | 最小化优化，无需访问表 | 最优情况 |
+
+```sql
+-- 看到 WARNING 时的排查思路
+EXPLAIN SELECT * FROM orders
+WHERE YEAR(created_at) = 2025;
+-- Extra: Using where; Using filesort
+-- 问题：YEAR() 函数作用于字段 → 无法使用索引
+-- 优化：改用范围查询
+-- WHERE created_at >= '2025-01-01' AND created_at < '2026-01-01'
+```
+
+## 代码示例
+
+```sql
+-- 典型 EXPLAIN 输出解读
+EXPLAIN SELECT u.name, o.amount
+FROM users u
+JOIN orders o ON u.id = o.user_id
+WHERE u.status = 1
+ORDER BY o.created_at DESC
+LIMIT 10;
+
+-- 解读要点：
+-- 第一行：u 表 → select_type=PRIMARY, type=ref (status 上有索引)
+--         → key=idx_status, rows≈500, filtered=100%
+-- 第二行：o 表 → type=ref (user_id 是外键索引), eq_ref
+--         → 对每个 u 的行，通过 user_id 精确匹配一条订单
+-- Extra: Using index condition → ICP 生效
+--          Using filesort → created_at 上没有合适索引，需额外排序
+-- 优化方向：给 orders(created_at) 建索引，消除 filesort
+```
+
+## 实践场景
+
+**场景一：日常慢查询排查**
+1. 开启慢查询日志（`long_query_time=1`）
+2. 对慢 SQL 加 `EXPLAIN` 前缀执行
+3. 检查 type 是否退化到 `ALL` 或 `index`
+4. 关注 Extra 中的 `Using temporary` 和 `Using filesort`
+5. 针对问题点调整索引或改写 SQL
+
+**场景二：判断索引是否被有效利用**
+```sql
+-- 如果发现某张表的 key 列为 NULL，说明该查询完全没有使用索引
+-- 检查 possible_keys 是否有可选索引但未被选中
+-- 如果是，可能是统计信息过时，执行 ANALYZE TABLE
+
+ANALYZE TABLE orders;
+```
+
+**场景三：JOIN 查询优化**
+- 小表驱动大表：JOIN 中较小的表放在前面（EXPLAIN 靠上的表先被执行）
+- 确保 JOIN 条件两侧都有对应的索引
+- 避免在多列上使用 OR 连接 JOIN 条件，这会迫使优化器退化为全表扫描
+
+## 扩展阅读
+- [[B+树索引原理]]
+- [[覆盖索引与回表优化]]
+- [[ACID 与 MVCC 机制]]
@@ -0,0 +1,174 @@
+---
+tags: [mysql, covering-index, index-pushdown, most-left-prefix, composite-index]
+create time: 2026-08-08 18:00
+update time: 2026-08-08 18:00
+---
+
+# 覆盖索引与回表优化
+
+## 概述
+
+覆盖索引（Covering Index）是 MySQL 查询优化的核心技术之一。当查询所需的列全部可以由某个索引直接提供时，引擎无需访问聚簇索引中的完整行数据，从而大幅减少磁盘 IO 和 CPU 开销。理解回表的成本、如何识别覆盖索引以及如何通过索引下推（ICP）进一步降低回表次数，是每个后端工程师调优必会的技能。
+
+## 核心原理
+
+### 回表的完整过程
+
+回表是指通过二级索引查询到主键后，再用主键回到聚簇索引中获取完整行记录的步骤。这个过程涉及两次 B+树查找：
+
+```mermaid
+sequenceDiagram
+    participant Q as 查询请求
+    participant SI as 二级索引 B+树
+    participant PK as 主键值
+    participant CI as 聚簇索引 B+树
+    participant Row as 完整行数据
+    participant R as 返回结果
+
+    Q->>SI: 根据二级索引条件定位
+    SI-->>Q: 找到满足条件的记录
+    Note over SI,Q: 例：idx_status(status)<br/>status='active' → PK=1001
+    Q->>PK: 提取主键值 PK=1001
+
+    PK->>CI: 以 PK=1001 在聚簇索引中查找
+    CI-->>PK: 定位到对应叶子节点
+    PK->>Row: 取出完整行数据
+    Row->>R: 返回 {id:1001, status:'active', ...}
+```
+
+**回表成本分析**：
+- 每次回表都是一次独立的 B+树搜索，至少涉及 3~4 次磁盘 IO（假设树高为 3~4 层）
+- 如果二次查询需要过滤大量数据，回表次数成倍增长
+- 回表造成的随机 IO 比顺序 IO 慢数十倍
+
+### 覆盖索引的概念与识别
+
+**覆盖索引**：查询只需要从索引树中就能获取所有需要的数据，无需回表。
+
+判断是否覆盖索引的方法非常简单：看 EXPLAIN 结果的 `Extra` 列是否出现 **"Using index"**。
+
+```sql
+EXPLAIN SELECT id, name FROM users WHERE name = 'Alice';
+-- Extra: Using index
+-- 解释：idx_name 索引已包含 name 和隐含的主键 id，无需回表
+```
+
+注意：`Using index` 并不等同于"用了覆盖索引"，还需要结合具体索引定义来判断。更准确的判断方式是看 `Key` 列使用的索引是否真的覆盖了查询的所有列。
+
+> [!TIP] MySQL 8.0 新增指示符
+> - `Using index condition`：索引下推（ICP），部分过滤在存储引擎层完成
+> - `Using where; Using index`：真正的覆盖索引，无需回表
+> - `Using index`（不带 where）：可能是前缀覆盖，需确认查询列是否完全在索引中
+
+### 索引下推（Index Condition Pushdown, ICP）
+
+ICP 是 MySQL 5.6 引入的优化技术，用于减少回表次数。
+
+**没有 ICP 的情况**：
+1. 二级索引遍历到满足条件的记录
+2. 立即回表取完整行
+3. 在 Server 层用 WHERE 条件过滤
+
+**有 ICP 的情况**：
+1. 二级索引遍历到候选记录
+2. **在存储引擎层先用索引中包含的列做 WHERE 过滤**
+3. 只有通过过滤的记录才回表
+
+这省去了不必要的回表 IO，尤其对多条件查询中最后一个不在索引前列的条件非常有效。
+
+```sql
+-- 复合索引 (name, age, email)
+-- WHERE name = 'Alice' AND age > 20
+-- name 在索引前列，age 也在索引中 → ICP 可发挥作用
+-- 如果改为 WHERE name = 'Alice' AND email = 'a@x.com'
+-- email 不在索引前列但仍在索引树中，ICP 仍有效
+```
+
+### 最左前缀原则详解
+
+复合索引 `(col1, col2, col3)` 的匹配规则类似于前缀树匹配：
+
+```sql
+INDEX idx_abc (a, b, c);
+
+a              ✅ 走索引全部三段
+a, b           ✅ 走索引前两段
+a, b, c        ✅ 走索引全部三段
+b              ❌ 跳过了 a，不走索引（除非有单独的 b 索引）
+a, c           ⚠️ 只用 a 这一段索引，c 无法使用前缀匹配
+b, c           ❌ 跳过 a，不走索引
+a, range_on_b, c ⚠️ a 和 b(range) 使用索引，但 c 因 b 的范围查询中断，不使用索引
+```
+
+> [!WARNING] 范围查询断链陷阱
+> 最常见的误解是"a,c 也能用到 c"。实际上，当遇到范围查询（>、<、BETWEEN、LIKE 'prefix%'）时，该列之后的索引列失效。例如：`WHERE a = 1 AND b > 10 AND c = 3`，只有 a 和 b 使用了索引，c 无法利用索引过滤。
+
+### 复合索引设计最佳实践
+
+1. **区分度高（基数大）的列放前面**
+   - 用户 ID 的区分度远高于性别，前者应放在复合索引的前面
+   - 可以用 `SELECT COUNT(DISTINCT col) / COUNT(*) AS selectivity` 估算
+
+2. **等值查询在前，范围查询在后**
+   - 范围查询一旦命中，同索引后面的列就无法利用
+
+3. **避免过度索引**
+   - 每个额外的索引都会增加 INSERT/UPDATE 的成本
+   - 一条 SQL 只能使用一个索引（MySQL 8.0 之前）
+
+4. **考虑排序需求**
+   - 如果经常按 `(status, created_at)` 排序，可以直接建这个复合索引，避免 filesort
+
+## 代码示例
+
+```sql
+-- 建表示例
+CREATE TABLE orders (
+    id BIGINT AUTO_INCREMENT PRIMARY KEY,
+    user_id BIGINT NOT NULL,
+    status TINYINT NOT NULL DEFAULT 0,
+    created_at DATETIME NOT NULL,
+    amount DECIMAL(10,2),
+    INDEX idx_uid_status (user_id, status),
+    INDEX idx_created (created_at)
+);
+
+-- 覆盖索引案例：查询只涉及索引列
+EXPLAIN SELECT user_id, status FROM orders WHERE user_id = 100 AND status = 1;
+-- Key: idx_uid_status
+-- Extra: Using index ← 覆盖索引，不回表
+
+-- 非覆盖索引案例：需要回表
+EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 1;
+-- Key: idx_uid_status
+-- Extra: Using where ← 需要回表
+
+-- ICP 优化案例：MySQL 5.6+ 自动启用
+EXPLAIN SELECT id, user_id, status FROM orders
+    WHERE user_id = 100 AND status IN (1, 2, 3)
+    AND amount > 100;
+-- amount 不在 idx_uid_status 索引中 → 需要回表
+-- 但 user_id + status 在索引中 → ICP 可以先过滤 status
+```
+
+## 实践场景
+
+**场景一：报表查询优化**
+- 常见的统计类查询往往只需要几个聚合列，完全可以构建专门的覆盖索引
+- 例如 `COUNT(user_id)` 只需建 `(status, user_id)` 索引即可覆盖，避免扫描整张表
+
+**场景二：高频接口缓存穿透防护**
+- 二级接口返回固定字段列表时，确保这些字段恰好落在某个二级索引上
+- 这样即使缓存失效，DB 层的查询开销也非常小
+
+**场景三：监控回表率**
+```sql
+-- 通过慢查询日志观察是否需要回表
+SHOW GLOBAL STATUS LIKE 'Handler_read%';
+-- Handler_read_next 持续增长且数值很高 → 可能存在大量回表
+```
+
+## 扩展阅读
+- [[B+树索引原理]]
+- [[Explain 执行计划解读]]
+- [[ACID 与 MVCC 机制]]