diff --git a/hhs/MySQL/06-事务与并发控制/26-锁机制总览.md b/hhs/MySQL/06-事务与并发控制/26-锁机制总览.md
index 1411e48..bf868bd 100644
--- a/hhs/MySQL/06-事务与并发控制/26-锁机制总览.md
+++ b/hhs/MySQL/06-事务与并发控制/26-锁机制总览.md
@@ -50,11 +50,27 @@ graph BT
style NKLock fill:#00B6BC,color:#fff
```
+### 场景矩阵 — 查询条件 → 锁类型速查
+
+```mermaid
+flowchart TD
+ Q{"查询方式"}
+
+ Q -->|"精确等值(unique index)"| R1["Record Lock
仅锁那条记录"]
+ Q -->|"精确等值(non-unique index)"| R2["Next-Key Lock
记录 + 左侧间隙"]
+ Q -->|"范围查询
WHERE id > 10"| R3["每个匹配记录的
Next-Key Lock + 最大值右侧间隙"]
+ Q -->|"无索引条件"| R4["全表记录的 Next-Key Lock
退化为表锁效果 ⚠️"]
+ Q -->|"DELETE | UPDATE | INSERT"| R5["INSERT: Gap Lock on gap
DELETE/UPDATE: Record Lock"]
+
+ style R1 fill:#00B6BC,color:#fff
+ style R4 fill:#EE5A24,color:#fff
+ style R5 fill:#FF9F43,color:#000
+```
> [!NOTE] 为什么需要三张图？
>
> - **第一张**展示锁的粒度层次：从全局→表→行
> - **第二张**展示行锁的子类关系：三种基础锁如何组合成临键锁
-> - **第三张**（下方场景矩阵）展示不同查询条件下 InnoDB 实际选择哪种锁
+> - **第三张**展示不同查询条件下 InnoDB 实际选择哪种锁（场景矩阵）
>
> 三者互为补充，共同构成完整的锁选型全景。带着这三张图，你可以回答面试中「InnoDB 锁到底有哪些类型」的问题了。
@@ -185,22 +201,58 @@ SELECT * FROM users WHERE id = 1 FOR UPDATE;
### 意向锁的作用
+意向锁解决的核心问题是：**当一个事务想加表级锁时，怎么快速知道"表里有没有人在锁行"？**
+
+没有意向锁 → 必须逐行扫描（百万行代价太高）。
+有了意向锁 → 看一眼表级标记就知道。
+
+#### 场景一：行级加锁流程
+
+事务想对某行加锁时，InnoDB **自动**在表级申请意向锁：
+
```mermaid
flowchart TD
- A["事务 A 想在行级加 X 锁"] --> B{"检查表级意向锁"}
- B --> C{"表中是否有其他事务的
意向共享锁 IS？"}
- C -->|有| D["冲突！不能同时拥有 IX + IS"]
- B -->|无| E{"表中是否有其他事务的
意向排他锁 IX？"}
- E -->|有| F["冲突！表级不支持多个 IX"]
- E -->|无| G["✅ 放行，加行级 X 锁"]
-
- style G fill:#00D866,color:#fff
- style D fill:#EE5A24,color:#fff
- style F fill:#EE5A24,color:#fff
+ A["事务想在行级加 X 锁"] --> IX["🔒 自动在表级加 IX 锁
（声明：我打算锁表里的某些行）"]
+ IX --> B{"表级是否有
S 锁或 X 锁？"}
+ B -->|"有"| C["⏳ 等待表级锁释放"]
+ B -->|"无"| D["✅ IX 加锁成功
→ 继续在行级加 X 锁"]
+
+ style D fill:#00D866,color:#fff
+ style C fill:#EE5A24,color:#fff
+ style IX fill:#FF9F43,color:#000
```
-> [!NOTE] 意向锁不是用户能控制的
-> 当事务准备对某行加 S 锁时，InnoDB 自动在表级加 IS；加 X 锁时自动加 IX。它的作用是快速判断「这张表有没有人在用」，而不必逐行扫描。
+> [!NOTE] IS 和 IX 之间、IX 和 IX 之间都**不冲突**
+> 因为意向锁只是"声明意图"，真正的冲突发生在**行级**。两个事务各自改不同行，表级意向锁完全可以共存。
+>
+> | 已持有 ↓ \ 请求 → | IS | IX | S | X |
+> |---|---|---|---|---|
+> | **IS** | ✅ | ✅ | ✅ | ❌ |
+> | **IX** | ✅ | ✅ | ❌ | ❌ |
+> | **S** | ✅ | ❌ | ✅ | ❌ |
+> | **X** | ❌ | ❌ | ❌ | ❌ |
+
+#### 场景二：表级加锁流程（意向锁的真正用途）
+
+当有人想给整张表加 S 锁或 X 锁时，**只需检查表级意向锁**，不用逐行扫描：
+
+```mermaid
+flowchart TD
+ A["事务想给表加
S 锁 / X 锁"] --> Q{"表级有没有 IX 锁？
（有人在做行级写入）"}
+ Q -->|有| B["⏳ 等待 IX 释放
（说明有人在改行数据）"]
+ Q -->|无| R{"表级有没有 IS 锁？
（有人在做行级读取）"}
+ R -->|"X 锁请求 + 有 IS"| B2["⏳ 等待 IS 释放"]
+ R -->|"S 锁请求 + 有 IS"| C["✅ IS 兼容 S 锁，放行"]
+ R -->|无| D["✅ 放行，加表级锁"]
+
+ style D fill:#00D866,color:#fff
+ style C fill:#00D866,color:#fff
+ style B fill:#EE5A24,color:#fff
+ style B2 fill:#EE5A24,color:#fff
+```
+
+> [!TIP] 一句话记住
+> 意向锁的真正价值不在于阻塞其他意向锁，而在于**让表级锁的兼容性判断变成 O(1)**——只看标记，不扫行。
## 记录锁、间隙锁、临键锁
@@ -231,12 +283,35 @@ SELECT * FROM orders WHERE status = 'pending' FOR UPDATE;
> [!QUESTION] Gap Lock 和 Record Lock 最大的区别是什么？
> Record Lock 锁的是"已经存在的东西"，Gap Lock 锁的是"还不存在但可能出现的东西"。一个是保护现在，一个是防止未来。
+> [!QUESTION] 那 InnoDB 怎么知道该锁哪个间隙？
+> 关键在于 B+ 树索引是**有序**的。当查询值不存在时，InnoDB 在索引上做查找，找到**刚好包围这个值的左右两条记录**——左边是 ≤ 查询值的最大记录，右边是 > 查询值的最小记录。这两条记录之间的区间，就是 InnoDB 要锁的间隙。
+>
+> 一句话总结：**"谁包围了这个值，间隙就是谁"**。
+
+索引上的值 `10, 20, 30, 40, 50` 把整条数轴切成了若干个间隙，目标值落在哪个间隙，就锁哪个：
+
+```mermaid
+graph LR
+ subgraph Gaps["索引记录切分出的间隙"]
+ direction LR
+ G0["(-∞, 10)"] --- R1["10"] --- G1["(10, 20)"] --- R2["20"] --- G2["(20, 30)"] --- R3["30"] --- G3["(30, 40)"] --- R4["40"] --- G4["(40, 50)"] --- R5["50"] --- G5["(50, +∞)"]
+ end
+
+ TARGET["查询 id=25"] -.->|25 落入此区间| G2
+
+ style G2 fill:#C44569,color:#fff,stroke-width:3px
+ style TARGET fill:#FF9F43,color:#000
+```
+
```sql
-- 假设索引上有以下值: 10, 20, 30, 40, 50
-- 锁定 (20, 30) 这个开区间
SELECT * FROM t WHERE id = 25 FOR UPDATE;
--- id=25 不存在 → 不锁记录，锁住包含 25 的间隙 (20, 30)
+-- InnoDB 在 B+ 树上查找 25：
+-- → 左边最近的记录: 20（≤ 25 的最大值）
+-- → 右边最近的记录: 30（> 25 的最小值）
+-- → 间隙 = (20, 30)，锁住它！
-- 其他事务不能在 (20, 30) 区间内插入任何值
```
@@ -385,12 +460,62 @@ flowchart TD
style R5 fill:#FF9F43,color:#000
```
-> [!TIP] 实用记忆法
+> [!TIP] 🧠 记忆卡片 1 — 锁类型三步判断法
>
> 看到一条 SQL，依次回答三个问题就能判断加锁类型：
-> 1. **有索引吗？** → 无索引 = 全表锁（❌）
-> 2. **是等值查询吗？** → 是 → 再看是否有唯一索引
-> 3. **是范围查询吗？** → 是 → 每个命中记录都加 Next-Key Lock
+>
+> ```mermaid
+> flowchart TD
+> Start{"SQL 会加锁吗？
（当前读？）"}
+> Start -->|"普通 SELECT"| Snap["❌ 一致性读
不加锁（MVCC）"]
+> Start -->|"SELECT FOR UPDATE/SHARE
UPDATE / DELETE / INSERT"| Q1{"1. 有索引吗？"}
+>
+> Q1 -->|"❌ 无索引"| Full["⚠️ 全表 Next-Key Lock
退化为表锁"]
+> Q1 -->|"✅ 有索引"| Q2{"2. 等值查询？"}
+>
+> Q2 -->|"是"| Q3{"3. 唯一索引？"}
+> Q3 -->|"唯一 + 命中"| RL["📌 Record Lock"]
+> Q3 -->|"唯一 + 未命中"| GL["🔒 Gap Lock"]
+> Q3 -->|"非唯一"| NKL["🔑 Next-Key Lock"]
+>
+> Q2 -->|"范围查询"| NKL2["🔑 每条命中记录
Next-Key Lock
+ 最大值右侧 Gap"]
+>
+> style RL fill:#00B6BC,color:#fff
+> style GL fill:#FF9F43,color:#000
+> style NKL fill:#C44569,color:#fff
+> style NKL2 fill:#C44569,color:#fff
+> style Full fill:#EE5A24,color:#fff
+> style Snap fill:#636e72,color:#fff
+> ```
+>
+> **口诀：无索引全表炸，唯一命中只锁行，其余都带间隙锁。**
+
+> [!TIP] 🧠 记忆卡片 2 — 锁兼容性速记
+>
+> | 已有 ↓ \ 请求 → | **S** | **X** |
+> |---|---|---|
+> | **S** | ✅ 共享读没问题 | ❌ 别人要写我得让 |
+> | **X** | ❌ 我在写你别读 | ❌ 我在写你别碰 |
+>
+> **口诀：读读兼容，读写互斥，写写互斥。** 意向锁（IS/IX）之间永远不冲突——它们只是"挂牌子声明意图"。
+
+> [!TIP] 🧠 记忆卡片 3 — RC vs RR 锁行为对比
+>
+> | | **RR（默认）** | **RC** |
+> |---|---|---|
+> | Gap Lock | ✅ 有（防幻读） | ❌ 无 |
+> | Next-Key Lock | ✅ 默认算法 | 退化为 Record Lock |
+> | 并发度 | 较低 | 较高 |
+> | 死锁概率 | 较高（Gap Lock 多） | 较低 |
+>
+> **口诀：RC 没有间隙锁，所以不会防幻读，但并发更高、死锁更少。**
+
+> [!TIP] 🧠 记忆卡片 4 — 死锁四板斧
+>
+> 1. **固定顺序** — 所有事务按同一顺序（如主键升序）访问资源
+> 2. **一次锁完** — 减少持锁期间的等待窗口
+> 3. **短事务** — 锁持有时间越短，冲突越少
+> 4. **降级到 RC** — 砍掉 Gap Lock，死锁概率大降
## 死锁与排查
diff --git a/hhs/MySQL/06-事务与并发控制/27-死锁与排查.md b/hhs/MySQL/06-事务与并发控制/27-死锁与排查.md
index b1e1c96..e3fae3d 100644
--- a/hhs/MySQL/06-事务与并发控制/27-死锁与排查.md
+++ b/hhs/MySQL/06-事务与并发控制/27-死锁与排查.md
@@ -7,7 +7,13 @@ create time: 2026-05-16 00:00
## 概述
-死锁是两个或多个事务互相等待对方释放锁资源的环形依赖。MySQL InnoDB 内置了死锁检测机制，会自动选择其中一个事务回滚来解除死锁。理解死锁的成因和排查方法是后端工程师的必备技能。
+死锁是两个或多个事务互相等待对方释放锁资源的环形依赖。打个比方：两个人各拿一把钥匙，但都需要对方手里的钥匙才能开门——谁也不松手，就永远卡住了。
+
+MySQL InnoDB 内置了死锁检测机制，发现死锁后会自动选择一个"牺牲者"回滚来解除死锁。但自动回滚不代表可以不管——**频繁死锁会严重影响吞吐量**，理解死锁的成因和排查方法是后端工程师的必备技能。
+
+> [!QUESTION] 在往下读之前，先想一个问题
+> 如果你的线上服务突然出现大量 `Deadlock found when trying to get lock` 报错，你的第一步应该做什么？
+> 带着这个问题往下读，你会在「排查工作流」部分找到答案。
## 常见死锁场景
@@ -15,19 +21,32 @@ create time: 2026-05-16 00:00
> 所有死锁都可以归结为同一个模式：**每个事务都持有对方需要的资源，同时又在等待对方持有的资源**。
> 想象两个人从桥的两端相向而行，桥只能容一人通过——谁也不退让，就卡住了。数据库里的"退让"就是回滚一个事务。
+```mermaid
+graph LR
+ T1["事务 A
持有 user_id=1 的锁"] -->|"等待 user_id=2 的锁"| T2["事务 B
持有 user_id=2 的锁"]
+ T2 -->|"等待 user_id=1 的锁"| T1
+
+ style T1 fill:#FF6B6B,color:#fff
+ style T2 fill:#4ECDC4,color:#fff
+```
+
### 场景一：交叉顺序加锁
**最经典、最容易复现的场景。** 核心原因是两个事务对相同资源的访问顺序不一致。
```sql
--- 事务 A -- 事务 B
-UPDATE accounts SET balance = balance - 100 WHERE user_id = 1; -- 加 X 锁 user_id=1
-UPDATE accounts SET balance = balance + 100 WHERE user_id = 2; -- 尝试加 X 锁 user_id=2 → 被 T2 阻塞
+-- Step 1: 两个事务各拿一把锁（关键：加锁顺序相反）
+-- 事务 A
+UPDATE accounts SET balance = balance - 100 WHERE user_id = 1; -- 拿到 user_id=1 的 X 锁
+-- 事务 B
+UPDATE accounts SET balance = balance + 100 WHERE user_id = 2; -- 拿到 user_id=2 的 X 锁
-UPDATE accounts SET balance = balance + 100 WHERE user_id = 1; -- 尝试加 X 锁 user_id=1 → 被 T1 阻塞
-UPDATE accounts SET balance = balance - 100 WHERE user_id = 2; -- 永远不会执行
-
--- 结果：T1 等 T2 的 user_id=2，T2 等 T1 的 user_id=1 → 死锁
+-- Step 2: 各自请求对方持有的锁 → 死锁
+-- 事务 A
+UPDATE accounts SET balance = balance + 100 WHERE user_id = 2; -- 等 user_id=2 → 被事务 B 挡住
+-- 事务 B
+UPDATE accounts SET balance = balance + 100 WHERE user_id = 1; -- 等 user_id=1 → 被事务 A 挡住
+-- → 事务 A 等事务 B，事务 B 等事务 A → 环形等待 → 死锁
```
> [!QUESTION] ❓ 思考一下
@@ -42,33 +61,51 @@ UPDATE accounts SET balance = balance - 100 WHERE user_id = 2; -- 永远不会
### 场景二：范围查询 + 间隙锁
+这个场景比场景一"隐蔽"得多——表面上只是普通的查询和插入，却因为 **Gap Lock（间隙锁）** 撞车了。
+
+> [!NOTE] 先搞懂：什么是 Gap Lock？
+> 想象一张表的 id 列有记录 `1, 5, 10`，它们之间存在两个"空隙"：`(1,5)` 和 `(5,10)`。
+>
+> 在 RR 隔离级别下，当你执行 `SELECT ... FOR UPDATE WHERE id BETWEEN 2 AND 9` 时，InnoDB 不仅锁住 id=5 这条记录本身，还会**锁住它两边的空隙**——这就是 Gap Lock。它的目的是：**防止你在这些空隙里插入新记录（防幻读）**。
+>
+> 就像你在图书馆书架上取下第 5 号书，顺手在 4 号和 6 号之间放了块"占位牌"——别人不能在这个位置插入新书。
+
> [!WARNING] RC vs RR 的关键差异
> 在 **REPEATABLE READ（RR）** 隔离级别下，InnoDB 会启用 Gap Lock。这意味着范围查询"锁定了一段区间"——不仅锁了存在的记录，还锁了它们之间的"空隙"。
> 如果你不需要可重复读保证，**考虑降级到 READ COMMITTED（RC）**，Gap Lock 将不复存在。
-```sql
--- 假设表中有 id = 1, 5, 10 三条记录
+下面用一个具体例子演示死锁是如何发生的。假设表中有 id = 1, 5, 10 三条记录：
--- 事务 A -- 事务 B
-BEGIN; BEGIN;
-SELECT * FROM items INSERT INTO items (id, name)
- WHERE id BETWEEN 2 AND 9 VALUES (5, 'item5');
- FOR UPDATE; -- 拿到 X 锁(id=5) + Gap(1,5) + Gap(5,10)
- -- Gap(5,10) 阻塞了下面的插入
-
-INSERT INTO items (id, name) INSERT INTO items (id, name)
- VALUES (5, 'test'); VALUES (7, 'new_item');
- -- 尝试插入 id=5 → -- 尝试插入 id=7 → 落入 Gap(5,10)
- -- 已被 T_A 的 NX 锁 -- 被 T_A 的 Gap Lock 阻塞！
- -- T_A 试图插入 id=7 → 被 T_B 阻塞
- -- → 死锁！
+```sql
+-- Step 1: 事务 A 先执行范围查询
+BEGIN;
+SELECT * FROM items WHERE id BETWEEN 2 AND 9 FOR UPDATE;
+-- 结果：查到 id=5 一条记录
+-- 隐含动作：对 id=5 加 X 锁 + Gap(1,5) + Gap(5,10)
+-- 这两个"空隙"被锁住，别人不能往里面插数据
```
-> [!NOTE] 为什么间隙锁会导致死锁？
-> 很多人不理解：`SELECT ... FOR UPDATE` 只是查数据，为什么要锁"不存在的记录"？
-> InnoDB 的设计哲学是：**防止幻读**。如果 T_A 查到 2~9 之间没有 id=7 的记录，等它稍后想插入时却被告知"已有人占了"，这就是幻读。所以它在 5 和 10 之间也加了一把"虚拟钥匙"。
+```sql
+-- Step 2: 事务 B 尝试往空隙里插入
+BEGIN;
+INSERT INTO items (id, name) VALUES (7, 'new_item');
+-- id=7 落在 Gap(5,10) 范围内 → 被事务 A 的 Gap Lock 阻塞
+-- 事务 B 拿到一个"插入意向锁"（Insert Intention Lock），在 Gap Lock 前排队
+```
+
+```sql
+-- Step 3: 事务 A 也要往同一个空隙里插
+INSERT INTO items (id, name) VALUES (5, 'test');
+-- id=5 已经存在，但 A 自己持有该记录的 X 锁，似乎可以直接插入？
+-- 问题出在这里：B 的"插入意向锁"和 A 的 Gap Lock 互斥
+-- A 要等 B 释放意向锁，B 在等 A 释放 Gap Lock → 双方互相等待 → 死锁！
+```
+
+> [!QUESTION] ❓ 灵魂拷问
+> 一个 `SELECT ... FOR UPDATE` 查数据的操作，为什么会和 `INSERT` 冲突？
+> 答案在于 InnoDB 的设计哲学：**防止幻读**。如果 A 查到 2~9 之间没有 id=7 的记录，等它稍后想插入时却被别人抢了先，这就是幻读。所以 Gap Lock 相当于给整个空隙加了"预约"。
>
-> 这个机制在大多数 OLTP 业务中是过度保护——换成 RC 就能彻底消除这类死锁。
+> 但在大多数 OLTP 业务中，这种保护是过度的——**换成 RC 隔离级别**就能彻底消除 Gap Lock，从根本上解决这类死锁。
### 场景三：批量操作的非确定性顺序
@@ -103,41 +140,54 @@ DELETE FROM orders WHERE id IN (
SHOW ENGINE INNODB STATUS\G
```
-切换到 `trx` 段（向下滚动），定位到 `LATEST DETECTED DEADLOCK` 区域：
+切换到 `trx` 段（向下滚动），定位到 `LATEST DETECTED DEADLOCK` 区域。下面逐行拆解一份真实的死锁日志，关键信息已用注释标注：
```
------------------------
LATEST DETECTED DEADLOCK
------------------------
-2026-05-16 10:30:45.123
-*** (1) TRANSACTION:
+2026-05-16 10:30:45.123 -- ① 死锁发生的时间点
+
+*** (1) TRANSACTION: -- ② 事务 1 的基本信息
TRANSACTION 123456, ACTIVE 5 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 7890, OS thread handle 140123, query id id 12345
+-- "ACTIVE 5 sec"：事务已经运行了 5 秒
+-- "LOCK WAIT"：正在等待锁
-*** (1) WAITING FOR THIS LOCK to be granted:
+*** (1) WAITING FOR THIS LOCK to be granted: -- ③ 事务 1 在等什么锁？
RECORD LOCKS space id 42 page no 12 n bits 72 index PRIMARY of table `app`.`orders`
trx id 123456 lock_mode X locks rec but not gap waiting
Record lock, heap no 5 PHYSICAL RECORD: p8: 0x55 length 6: 1001
+-- "index PRIMARY"：锁在主键索引上
+-- "lock_mode X"：要拿排他锁（X锁 = 写锁）
+-- "rec but not gap"：只锁记录本身，不锁间隙
+-- "heap no 5"：物理位置第 5 行，对应记录值 1001
-*** (2) TRANSACTION:
+*** (2) TRANSACTION: -- ④ 事务 2 的基本信息
TRANSACTION 123457, ACTIVE 3 sec inserting
mysql tables in use 1, locked 1
-*** (2) HOLDING THE LOCK(S):
+*** (2) HOLDING THE LOCK(S): -- ⑤ 事务 2 持有哪些锁？
RECORD LOCKS space id 42 page no 12 n bits 72 index PRIMARY of table `app`.`orders`
trx id 123457 lock mode S locks rec but not gap
Record lock, heap no 5 PHYSICAL RECORD: p8: 0x55 length 6: 1001
+-- 事务 2 持有 id=1001 的共享锁（S锁 = 读锁）
-*** (2) WAITING FOR THIS LOCK to be granted:
+*** (2) WAITING FOR THIS LOCK to be granted: -- ⑥ 事务 2 在等什么锁？
RECORD LOCKS space id 42 page no 13 n bits 72 index idx_status of table `app`.`orders`
trx id 123457 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: p8: 0x44 length 6: 2001
+-- 事务 2 在等 idx_status 索引上 id=2001 的排他锁
+-- 但这个锁被事务 1 持有（日志中省略了这部分）
-*** WE ROLL BACK TRANSACTION (2)
+*** WE ROLL BACK TRANSACTION (2) -- ⑦ InnoDB 选择回滚事务 2
```
+> [!TIP] 快速读懂日志的口诀
+> **"谁在等什么，谁拿着什么，谁被杀了"** —— 三句话就能说清一次死锁。
+
### 解读模板
> [!CHECKLIST] 逐行拆解法
@@ -168,15 +218,17 @@ Transaction 2: 持有的锁 → 等待的锁（将被回滚的那个）
```sql
-- 查看当前阻塞链（谁在等谁）
SELECT
- r.trx_id AS waiting_trx_id,
- r.trx_mysql_thread_id AS waiting_thread,
- r.req_query AS waiting_query,
- b.trx_id AS blocking_trx_id,
+ r.trx_id AS waiting_trx_id, -- 被阻塞的事务 ID
+ r.trx_mysql_thread_id AS waiting_thread, -- 被阻塞的线程（对应 SHOW PROCESSLIST 中的 Id）
+ r.trx_query AS waiting_query, -- 被阻塞的 SQL（可能为 NULL，如果事务还没发新 SQL）
+ b.trx_id AS blocking_trx_id, -- 持有锁的事务 ID（"罪魁祸首"）
b.trx_mysql_thread_id AS blocking_thread,
- b.trx_query AS blocking_query
-FROM performance_schema.data_lock_waits AS w
-INNER JOIN information_schema.innodb_trx AS b ON w.requesting_engine_tx_id = b.trx_id
-INNER JOIN information_schema.innodb_trx AS r ON w.blocking_engine_tx_id = r.trx_id;
+ b.trx_query AS blocking_query -- 持有锁的事务正在执行的 SQL
+FROM performance_schema.data_lock_waits AS w -- 锁等待关系表：记录"谁在等谁"
+INNER JOIN information_schema.innodb_trx AS b
+ ON w.blocking_engine_transaction_id = b.trx_id -- 通过阻塞关系找到"持有锁的事务"
+INNER JOIN information_schema.innodb_trx AS r
+ ON w.requesting_engine_transaction_id = r.trx_id; -- 找到"等待锁的事务"
```
> [!NOTE] performance_schema vs SHOW ENGINE
@@ -185,21 +237,24 @@ INNER JOIN information_schema.innodb_trx AS r ON w.blocking_engine_tx_id = r
>
> 生产环境建议两者配合：`innodb_print_all_deadlocks` 兜底 + 监控脚本轮询 `data_lock_waits`。
+> [!QUESTION] ❓ 实际使用技巧
+> 如果 `waiting_query` 显示为 NULL，说明该事务还在等上一条 SQL 的锁。此时可以结合 `blocking_query` 定位持有锁的 SQL——**找到"持锁者"比找"等待者"更重要**，因为优化"持锁者"才能从根本上释放锁。
+
### 乐观锁替代方案
-并非所有场景都需要排他锁。考虑使用乐观锁（Optimistic Locking）来从根本上消除冲突：
+并非所有场景都需要排他锁。乐观锁的核心思想是：**不提前加锁，而是在提交时检查数据有没有被别人改过**——如果被改了，就重试。
```sql
--- 悲观锁：先加锁再判断
+-- 悲观锁：先加锁再操作（别人只能排队等）
BEGIN;
-SELECT balance FROM accounts WHERE user_id = 1 FOR UPDATE; -- 直接锁住
+SELECT balance FROM accounts WHERE user_id = 1 FOR UPDATE; -- 直接锁住，别人进不来
UPDATE accounts SET balance = 900 WHERE user_id = 1;
COMMIT;
--- ✅ 乐观锁：先改再校验（基于版本号）
+-- ✅ 乐观锁：先改再校验（基于版本号，不阻塞任何人）
UPDATE accounts SET balance = 900, version = version + 1
WHERE user_id = 1 AND version = 5; -- 只有版本仍为 5 时才更新
--- affected_rows = 1 → 成功；affected_rows = 0 → 重试
+-- affected_rows = 1 → 成功；affected_rows = 0 → 说明别人先改了，重试
```
> [!QUESTION] ❓ 什么时候该用乐观锁？
@@ -213,27 +268,27 @@ flowchart TD
B --> C["提取涉及的事务 SQL"]
C --> D["复现死锁场景"]
D --> E{"根因分析"}
-
+
E -->|"加锁顺序不一致"| F["统一加锁顺序"]
E -->|"范围查询间隙锁"| G["缩小 WHERE 范围
或改用 RC"]
E -->|"批量操作无序"| H["ORDER BY 主键后再操作"]
E -->|"大事务持锁时间长"| I["拆小事务
减少持锁范围"]
-
+
F --> J["压测验证"]
G --> J
H --> J
I --> J
-
+
J --> K{"死锁消失？"}
- K -->|是| L["🎉 上线监控"]
+ K -->|是| L["上线监控"]
K -->|否| D
-
+
style L fill:#00D866,color:#fff
```
## Go 中的死锁处理
-在 Go 应用层应对死锁的核心思路是：**捕获错误码 1213 → 回滚事务 → 重试**。
+在 Go 应用层应对死锁的核心思路是：**捕获错误码 1213 → 回滚事务 → 指数退避 → 重试**。
```go
import (
diff --git a/hhs/MySQL/06-事务与并发控制/28-一致性读与当前读.md b/hhs/MySQL/06-事务与并发控制/28-一致性读与当前读.md
index fc4eb81..46797cd 100644
--- a/hhs/MySQL/06-事务与并发控制/28-一致性读与当前读.md
+++ b/hhs/MySQL/06-事务与并发控制/28-一致性读与当前读.md
@@ -84,6 +84,32 @@ flowchart LR
2. **在新行上记录前一个版本的回滚指针** (`DB_ROLL_PTR`)
3. 更新 `DB_TRX_ID` 为当前事务 ID
+### 具体示例：一行数据经历三次 UPDATE
+
+```sql
+-- 初始: INSERT INTO product(id, name, price) VALUES(1, '键盘', 200);
+-- 行记录: {id=1, name='键盘', price=200, DB_TRX_ID=50, DB_ROLL_PTR=NULL}
+```
+
+随后三个事务依次修改 `price`：
+
+| 操作 | 聚簇索引中的行 | undo log 新增节点 |
+|------|---------------|-----------------|
+| 初始 INSERT | `{price=200, trx=50, roll_ptr=NULL}` | — |
+| TXN 60: `SET price=180` | `{price=180, trx=60, roll_ptr→undo_1}` | undo_1: `{price=200, trx=50}` |
+| TXN 70: `SET price=150` | `{price=150, trx=70, roll_ptr→undo_2}` | undo_2: `{price=180, trx=60}` |
+| TXN 80: `SET price=99` | `{price=99, trx=80, roll_ptr→undo_3}` | undo_3: `{price=150, trx=70}` |
+
+此时 version chain 为：
+
+```
+聚簇索引行(price=99) ──roll_ptr──→ undo_3(price=150) ──→ undo_2(price=180) ──→ undo_1(price=200)
+ trx=80 trx=70 trx=60 trx=50
+```
+
+> [!TIP] 类比理解
+> 把 version chain 想象成「编辑历史」——每次修改都不会覆盖原文，而是把旧版本存进回收站（undo log），新版本放回桌面（聚簇索引）。一致性读就是根据你打开文档的时间点，去回收站翻找对应的版本。
+
> [!QUESTION] 为什么是链表而不是数组？
> 因为版本数量在写入时无法预知。链表允许 O(1) 追加新版本，且通过 `DB_ROLL_PTR` 可以高效遍历——只沿着真正需要回溯的路径走。
@@ -109,43 +135,43 @@ flowchart TD
style I fill:#FF6B6B,color:#fff
```
-> [!NOTE] 可见性判断规则
-> - 若 `trx_id == ReadView.m_ids` 中的某个值 → **当前事务自己改的，可见**
-> - 若 `trx_id < min_trx_id` → **提交于快照之前的，可见**
-> - 若 `trx_id >= max_trx_id` → **提交于快照之后的，不可见**
-> - 若在 `[min_trx_id, max_trx_id)` 之间且在 `m_ids` 列表中 → **可见（该事务在 ReadView 创建时未提交）**
-> - 若在 `[min_trx_id, max_trx_id)` 之间但**不在** `m_ids` 列表中 → **不可见（该事务已提交）**
+> [!NOTE] 可见性判断规则（5 条，从上到下依次判断）
+> 1. `trx_id == 当前事务 ID` → ✅ **自己改的，可见**
+> 2. `trx_id < min_trx_id` → ✅ **快照前已提交，可见**
+> 3. `trx_id >= max_trx_id` → ❌ **快照后才启动，不可见**
+> 4. `trx_id ∈ [min_trx_id, max_trx_id)` 且**在 `m_ids` 中** → ❌ **快照时尚未提交，不可见**
+> 5. `trx_id ∈ [min_trx_id, max_trx_id)` 且**不在 `m_ids` 中** → ✅ **快照前已提交，可见**
+>
+> > 核心直觉：`m_ids` 就是「快照瞬间还在跑的事务名单」，名单上的事务其修改对当前快照**不可见**。
### 一致性读的完整流程
```mermaid
flowchart TD
- A["普通 SELECT"] --> B{"目标行是否有锁?"}
-
- B -->|无锁| C["直接读取当前行"]
-
- B -->|有锁| D["跳过当前行"]
- D --> E{"DB_ROLL_PTR 是否存在?"}
-
- E -->|否| F["无可视版本, 返回空"]
- E -->|是| G["跟随指针读取 undo log 旧版本"]
+ A["普通 SELECT"] --> B["读取当前行最新版本"]
+ B --> C{"用 ReadView 判断
DB_TRX_ID 是否可见?"}
+
+ C -->|可见| D["✅ 返回此版本"]
+ C -->|不可见| E{"DB_ROLL_PTR 是否存在?"}
+
+ E -->|否| F["❌ 无可视版本, 返回空"]
+ E -->|是| G["沿 DB_ROLL_PTR 读取 undo log 旧版本"]
G --> H{"旧版本 trx_id 可见?"}
-
- H -->|是| I["✅ 返回可见版本"]
- H -->|否| J{"还有更早版本?"}
-
- J -->|是| G
- J -->|否| F
-
- C --> K["返回结果"]
- I --> K
- F --> K
-
- style B fill:#FF9F43,color:#000
- style I fill:#00D866,color:#fff
+
+ H -->|可见| D
+ H -->|不可见| I{"还有更早版本?"}
+
+ I -->|是| G
+ I -->|否| F
+
+ style C fill:#FF9F43,color:#000
+ style D fill:#00D866,color:#fff
style F fill:#FF6B6B,color:#fff
```
+> [!NOTE] 与之前版本的区别
+> 一致性读**不关心行上有没有锁**——它总是从最新版本开始，通过 ReadView 的可见性规则决定该版本是否对当前事务可见。不可见就沿 undo chain 往回找，直到找到第一个可见版本（或链尾）。
+
> [!TIP] 一致性读的性能优势
> 由于不需要加锁、不需要等待锁释放，一致性读在大量只读场景下几乎不产生并发开销。这就是为什么报表查询、数据导出都应该用普通 `SELECT`——既不影响业务写入，也避免了自己被阻塞。
@@ -154,6 +180,66 @@ flowchart TD
> [!NOTE] 为什么叫「快照读」？
> 因为它读的不是磁盘上的最新数据，而是某个时间点的数据「快照」。在 RR 模式下，这个快照在事务第一次 SELECT 时就冻结了；在 RC 模式下，每次 SELECT 都刷新快照。
+### 端到端示例：跟着 ReadView 走一遍
+
+> [!QUESTION] 先想想：如果三个事务交替修改同一行，第四个事务来做一致性读，它到底看到谁的版本？
+
+假设有一行 `account(id=1, balance=1000)`，当前 `max_trx_id = 104`：
+
+| 时间 | 事务 | 操作 | 状态 |
+|------|------|------|------|
+| T1 | TXN 101 | `UPDATE balance=900` | 已提交 ✅ |
+| T2 | TXN 102 | `UPDATE balance=800` | 未提交 🔒 |
+| T3 | TXN 103 | `UPDATE balance=700` | 已提交 ✅ |
+| T4 | **TXN 104（我们）** | `BEGIN; SELECT balance` | 开始一致性读 |
+
+此时 InnoDB 构建 ReadView：
+
+```
+m_ids = [102] ← 快照时仍在运行的事务（只有 TXN 102 未提交）
+min_trx_id = 102
+max_trx_id = 105 ← 下一个待分配的事务 ID
+```
+
+行的 version chain（从新到旧）：
+
+```
+balance=700 (trx=103) ← balance=800 (trx=102) ← balance=900 (trx=101) ← balance=1000 (trx=旧)
+```
+
+一致性读沿 version chain 逐版本判断：
+
+1. **trx=103**：在 `[102,105)` 内且**不在** m_ids 中 → 已提交 → ✅ 可见
+2. 直接返回 `balance=700`，不再往后找
+
+> [!TIP] 关键洞察
+> 虽然最新版本是 `balance=700`（trx=103），但如果你把 TXN 103 提交撤销、让 trx=102 先提交，那我们就会跳过 trx=102 的版本（它在 m_ids 中不可见），最终看到 trx=101 的 `balance=900`。可见性判断完全取决于「谁在快照瞬间已经提交」。
+
+### RR vs RC 的快照时机差异
+
+```mermaid
+sequenceDiagram
+ participant T as TXN A (RR 模式)
+ participant T2 as TXN B
+ participant DB as InnoDB
+
+ Note over T: BEGIN
+ T->>DB: SELECT balance FROM account WHERE id=1
+ Note over T,DB: 快照创建 (ReadView #1)
+
+ T2->>DB: UPDATE balance=500 WHERE id=1
+ T2->>DB: COMMIT
+
+ T->>DB: SELECT balance FROM account WHERE id=1
+ Note over T,DB: 复用 ReadView #1 → 看不到 500
+
+ T->>DB: SELECT balance FROM account WHERE id=1
+ Note over T,DB: 仍然复用 ReadView #1 → 还是看不到 500
+ Note over T: 整个事务期间看到的值始终一致
+```
+
+如果 TXN A 用的是 **RC 模式**，每次 SELECT 都会创建新的 ReadView，第二次 SELECT 就能看到 `balance=500`。
+
## 深入理解当前读
```sql
diff --git a/hhs/MySQL/07-高可用与分布式/30-主从复制详解.md b/hhs/MySQL/07-高可用与分布式/30-主从复制详解.md
index c07cb7c..f47f95d 100644
--- a/hhs/MySQL/07-高可用与分布式/30-主从复制详解.md
+++ b/hhs/MySQL/07-高可用与分布式/30-主从复制详解.md
@@ -9,21 +9,32 @@ create time: 2026-05-16 10:30
MySQL 主从复制是通过 Binlog 将主库的数据变更传播到从库的过程。它是高可用架构的基础组件，也是读写分离的前提。
+> [!tip] 生活中的类比
+> 想象主库是一位「主播」，从库是「观众」。主播做了一个操作（比如画画），观众通过直播画面（Binlog）看到这个操作，然后在自己的画布上**照着做一遍**。
+>
+> 这个"看到 → 照做"的过程，就是主从复制的本质。
+
+> [!question] 为什么需要主从复制？
+> 一台 MySQL 能撑多久？当读请求暴增时，单机性能到顶了怎么办？
+> 主从复制给出了两个关键答案：**读写分离**（主库写、从库读）和**高可用**（主库挂了，从库顶上）。
+
## 复制架构
+复制的过程可以简化为三个步骤：**主库记录变更** → **网络传输** → **从库重放变更**。
+
```mermaid
flowchart LR
subgraph "Master"
- M1["业务写入 → DML"] --> M2["Server 层生成 Binlog"]
+ M1["业务写入 DML"] --> M2["Server 层生成 Binlog"]
M2 --> M3["Binlog Dump Thread"]
end
subgraph "Network"
- M3 -.Binlog Stream.-> I1["IO Thread"]
+ M3 -. "Binlog Stream" .-> I1["IO Thread"]
end
-
+
subgraph "Slave"
- I1 --> S1["Relay Log
中继日志"]
+ I1 --> S1["Relay Log 中继日志"]
S1 --> S2["SQL Thread"]
S2 --> S3["数据文件更新"]
end
@@ -40,24 +51,37 @@ flowchart LR
| **IO Thread** | Slave | 连接 Master，拉取 binlog 写入本地 Relay Log |
| **SQL Thread** | Slave | 读取 Relay Log 重放应用到本地数据库 |
+> [!question] 为什么要多一个 Relay Log，而不是直接在从库上执行？
+> 其实这和消息队列的「削峰填谷」是一个道理。Relay Log 起到了**缓冲区**的作用：即使从库暂时卡住了（比如正在做慢查询），主库发来的 Binlog 也不会丢失，先暂存在 Relay Log 里，等从库空闲了再慢慢回放。
+
## 同步模式
+复制的「同步」和「异步」，核心问题只有一个：**主库写完后，要不要等从库确认？**
+
+| 模式 | 等不等从库？ | 数据安全 | 性能 |
+|------|------------|---------|------|
+| **异步** | 不等 | 低（可能丢数据） | 最高 |
+| **半同步** | 至少等 1 个 | 中（大幅降低丢数据概率） | 中 |
+| **组复制** | 等多数派共识 | 高 | 较低 |
+
+下面的流程图展示了三种模式的完整过程：
+
```mermaid
flowchart TD
- subgraph "异步复制 Async"
+ subgraph "Async 异步复制"
A1["Client 写入 Master"] --> A2["Master 刷盘返回 OK"]
A2 -->|"后续"| A3["异步发给 Slave"]
end
-
- subgraph "半同步复制 Semi-Sync"
+
+ subgraph "Semi-Sync 半同步复制"
S1["Client 写入 Master"] --> S2["Master 刷盘"]
- S2 --> S3["等待 ≥1 个 Slave ACK"]
- S3 -->|"超时 10s"| S4["降级为异步 ⚠️"]
+ S2 --> S3["等待至少1个 Slave ACK"]
+ S3 -->|"超时10s"| S4["降级为异步"]
S3 -->|"收到 ACK"| S5["返回 OK"]
S5 --> S6["异步发给其他 Slave"]
end
-
- subgraph "组复制 Group Replication"
+
+ subgraph "Group Replication 组复制"
G1["Client 写入"] --> G2["Paxos 共识"]
G2 --> G3["多数派确认"]
G3 --> G4["并行回放"]
@@ -72,6 +96,8 @@ flowchart TD
最简单的模式——Master 写完就不管了，异步发给 Slave。
+**在从库上执行以下命令**，告诉它"去连接哪个主库、用什么账号、从哪里开始复制"：
+
```sql
-- MySQL 5.5 (已弃用)
-- CHANGE MASTER TO
@@ -79,37 +105,42 @@ flowchart TD
-- ✅ MySQL 8.0+ 标准语法
CHANGE REPLICATION SOURCE TO
- SOURCE_HOST='10.0.1.10',
- SOURCE_USER='repl_user',
+ SOURCE_HOST='10.0.1.10', -- 主库 IP
+ SOURCE_USER='repl_user', -- 专用的复制账号
SOURCE_PASSWORD='password',
SOURCE_PORT=3306,
- SOURCE_AUTO_POSITION = 1; -- GTID 模式自动定位
+ SOURCE_AUTO_POSITION = 1; -- GTID 模式：自动找到正确的起始位置
-START REPLICA;
+START REPLICA; -- 启动复制！
```
-> [!WARNING] 异步复制的风险
+> [!tip] 关键参数 `SOURCE_AUTO_POSITION`
+> 设为 `1` 表示开启 GTID 自动定位——从库会自动告诉主库"我已经有哪些事务了"，主库从缺失的部分开始发送。再也不用手动查 Binlog 文件和偏移量了。
+
+> [!warning] 异步复制的风险
> Master 宕机后，尚未传输到 Slave 的数据会丢失。对于金融系统这是不可接受的。
### 半同步复制（Semi-Sync）
至少一个从库确认收到 Binlog 后，Master 才返回写成功。
+半同步需要在**主库和从库两端都开启**插件：
+
```ini
-# Master 端配置
-plugin_load_add = semisync_master
-rpl_semi_sync_master_enabled = 1
-rpl_semi_sync_master_timeout = 10000 # 10 秒超时后降级为异步
-rpl_semi_sync_master_wait_point = AFTER_SYNC # 刷盘后再等待
+# === Master 端配置 ===
+plugin_load_add = semisync_master # 加载半同步主库插件
+rpl_semi_sync_master_enabled = 1 # 开启
+rpl_semi_sync_master_timeout = 10000 # 10 秒收不到 ACK 就降级为异步（保护性能）
+rpl_semi_sync_master_wait_point = AFTER_SYNC # 先刷盘，再等从库确认（避免幻读）
```
```ini
-# Slave 端配置
-plugin_load_add = semisync_slave
-rpl_semi_sync_slave_enabled = 1
+# === Slave 端配置 ===
+plugin_load_add = semisync_slave # 加载半同步从库插件
+rpl_semi_sync_slave_enabled = 1 # 开启
```
-> [!NOTE] 半同步不是银弹
+> [!note] 半同步不是银弹
> - 从库收到 Binlog ≠ 已从磁盘持久化
> - 如果 Master 和从库同时断电，仍可能丢数据
> - 网络分区时 Master 会超时降级为异步
@@ -120,6 +151,12 @@ rpl_semi_sync_slave_enabled = 1
GTID（Global Transaction Identifier）给每个事务分配全局唯一的 ID，替代传统的 position-based 复制。
+> [!question] 为什么传统 Position 复制让人抓狂？
+> 传统模式下，从库靠 `mysql-bin.000003:154`（文件名 + 偏移量）来记录复制进度。
+> 想象一下：主库挂了，你要把从库切到新主库上，但新旧主库的 Binlog 文件名和偏移量完全不同——你得**手动计算**该从哪个位置继续复制。
+>
+> GTID 的思路就简单多了：给每个事务贴一个「身份证号」。无论主库怎么切换，从库只要说"我已经执行到 23 号事务了"，新主库就知道该从 24 号开始发。
+
```
GTID 格式: source_id:transaction_id
例: 3E11FA47-71CA-11E1-9E33-C80AA9429562:23
@@ -130,13 +167,13 @@ GTID 格式: source_id:transaction_id
```mermaid
flowchart TD
- A["Client 事务写入 Master"] --> B["Server 层分配 GTID
source_id:next_seq"]
- B --> C["写入 Binlog 事件
带 GTID 标记"]
- C --> D["Binlog Dump 线程发送
GTID + 事件到 Slave"]
- D --> E["Slave IO Thread 写入
Relay Log (含 GTID)"]
- E --> F{"GTID Set
是否已包含此 GTID?"}
- F -->|是| G["跳过重复事件 ✅"]
- F -->|否| H["SQL Worker 重放事务"]
+ A["Client 事务写入 Master"] --> B["Server 层分配 GTID"]
+ B --> C["写入 Binlog 事件, 带 GTID 标记"]
+ C --> D["Binlog Dump 线程发送 GTID 和事件到 Slave"]
+ D --> E["Slave IO Thread 写入 Relay Log"]
+ E --> F{"GTID Set 已包含此 GTID?"}
+ F -->|"是"| G["跳过重复事件"]
+ F -->|"否"| H["SQL Worker 重放事务"]
H --> I["更新 Slave gtid_executed"]
G --> J["继续下一个事件"]
I --> J
@@ -146,7 +183,7 @@ flowchart TD
style H fill:#00B6BC,color:#fff
```
-> [!NOTE] GTID 的一致性约束
+> [!note] GTID 的一致性约束
> 启用 `enforce_gtid_consistency = ON` 后，以下操作被**禁止**：
> - 对非事务引擎（如 MyISAM）的 DML
> - 创建/删除临时表
@@ -155,41 +192,62 @@ flowchart TD
### GTID vs 传统 Position
+一句话总结：**Position 靠「页码」定位，GTID 靠「身份证号」定位。**
+
| 特性 | Position-based | GTID-based |
|------|---------------|------------|
-| **定位方式** | 文件名 + position 号 | GTID set |
+| **定位方式** | 文件名 + position 号（像书签） | GTID set（像身份证号集合） |
| **跨库切换** | 需要手动查 position | 自动定位 |
| **跳过事务** | 困难 | `SET gtid_next = '...'; BEGIN; COMMIT; SET gtid_next = AUTOMATIC;` |
| **一致性检查** | 手动比对 | `pt-table-checksum` + GTID 验证 |
+> [!tip] 实际建议
+> MySQL 8.0 中 GTID 已经非常成熟，**新项目强烈建议默认开启**。传统 Position 模式仅在兼容老版本时使用。
+
+在主库和从库的 `my.cnf` 中添加以下配置即可启用 GTID：
+
```ini
# 启用 GTID
-gtid_mode = ON
-enforce_gtid_consistency = ON
-master_info_repository = TABLE # 复制信息存在表中而非文件
+gtid_mode = ON # 开启 GTID
+enforce_gtid_consistency = ON # 强制一致性：禁止不安全的 SQL 写法
+master_info_repository = TABLE # 复制元数据存到系统表，比文件更可靠
relay_log_info_repository = TABLE
```
+> [!tip] 热知识
+> MySQL 8.0 中 `master_info_repository` 和 `relay_log_info_repository` 默认就是 TABLE，无需手动配置。
+
## 并行复制（Multithreaded Slave, MTS）
+前面提到 SQL Thread 负责重放 Relay Log。问题来了——默认只有一个 SQL Thread，所有事务都**排队串行**执行。如果主库很忙，从库就很容易「越落越远」。
+
+> [!tip] 用快递仓库来理解并行复制
+> 串行回放 = 一个分拣员按顺序处理所有包裹。
+> 并行回放 = 多个分拣员**同时**处理，只要包裹之间没有依赖关系（比如不会同时操作同一行），就可以并行。
+
MySQL 5.6+ 引入从库并行回放，大幅提升复制延迟处理能力。
+在从库配置中开启并行复制：
+
```ini
# MySQL 5.x（已弃用）
# slave_parallel_type = LOGICAL_CLOCK
# slave_parallel_workers = 8
# ✅ MySQL 8.0+ 标准命名
-replica_parallel_type = LOGICAL_CLOCK # 基于 GTID 的并发回放
-replica_parallel_workers = 8 # 并发 worker 数量
+replica_parallel_type = LOGICAL_CLOCK # 按事务依赖关系决定哪些可以并行
+replica_parallel_workers = 8 # 并发 worker 数量（建议 CPU 核数的一半）
```
+> [!TIP] worker 数量设多少合适？
+> 不是越多越好。每个 worker 都占内存和 CPU，一般建议 **CPU 核数的一半**，上限不超过 16。设太多反而会因为锁竞争导致更慢。
+
### MTS 并行模式对比
```mermaid
flowchart LR
- subgraph "DATABASE（默认）"
- D1["Relay Log 事件"] --> D2{"按 database\n分桶"}
+ subgraph "DATABASE 默认"
+ D1["Relay Log 事件"] --> D2{"按 database 分桶"}
D2 -->|"db_a"| W1["Worker 1"]
D2 -->|"db_b"| W2["Worker 2"]
D2 -->|"db_c"| W3["Worker 3"]
@@ -197,9 +255,9 @@ flowchart LR
end
subgraph "GROUP_TRANSACTIONS"
- G1["Relay Log 事件"] --> G2{"判断事务\n依赖关系"}
- G2 -->|"无冲突"| A1["组 1 → 并行执行"]
- G2 -->|"有冲突"| A2["组 2 → 串行等待"]
+ G1["Relay Log 事件"] --> G2{"判断事务依赖关系"}
+ G2 -->|"无冲突"| A1["组1 并行执行"]
+ G2 -->|"有冲突"| A2["组2 串行等待"]
G1 -->|"无冲突"| A1
A1 --> J2["写入数据"]
A2 --> J2
@@ -217,23 +275,23 @@ flowchart LR
| **适用场景** | schema 设计良好的系统 | 多库共享、跨库事务较多的场景 |
| **引入版本** | MySQL 5.6 | MySQL 5.7+ |
-> [!TIP] 如何选择
+> [!tip] 如何选择
> - 如果业务按 database 做数据隔离（每个 tenant 一个 DB），选 `DATABASE`
> - 如果多个业务共享少数几个 database，选 `GROUP_TRANSACTIONS`
### LOGICAL_CLOCK 原理
-> [!INFO] `LOGICAL_CLOCK` = GTID 驱动的并行回放
+> [!info] `LOGICAL_CLOCK` = GTID 驱动的并行回放
> 无论选择 `DATABASE` 还是 `GROUP_TRANSACTIONS`，底层引擎都是 LOGICAL_CLOCK。
> 区别仅在于如何把连续事件流切分成可并行的逻辑组。
```mermaid
flowchart TD
A["Relay Log 事件流"] --> B{"按 database 分组"}
- B --> C["DB1 的事件队列"]
- B --> D["DB2 的事件队列"]
- B --> E["DBn 的事件队列"]
-
+ B --> C["DB1 事件队列"]
+ B --> D["DB2 事件队列"]
+ B --> E["DBn 事件队列"]
+
C --> W1["Worker 1 执行 DB1 事件"]
D --> W2["Worker 2 执行 DB2 事件"]
E --> Wn["Worker n 执行 DBn 事件"]
@@ -243,13 +301,15 @@ flowchart TD
style Wn fill:#FF9F43,color:#000
```
-> [!TIP] Parallel Replication 的限制
+> [!tip] Parallel Replication 的限制
> - 基于 database 的并行要求同一 database 内没有冲突事务
> - 跨 database 的操作无法并行
> - innodb_table_locks=OFF 且 autocommit=1 时才能并行（避免表锁冲突）
## 监控复制状态
+复制搭好了，日常巡检同样重要。最常见的关注点：**IO 线程和 SQL 线程是否在正常运行？从库落后主库多少秒？**
+
```sql
-- MySQL 8.0+ 已弃用 SHOW SLAVE STATUS
-- SHOW SLAVE STATUS\G
@@ -276,16 +336,18 @@ FROM (
## 常见问题与排查
+生产环境中，主从复制最容易出问题的三个地方：**IO 线程断连**、**SQL 线程卡住**、**延迟越来越大**。下面逐一分析。
+
### IO 线程断开（Slave_IO_Running: No）
```mermaid
flowchart TD
A["IO Thread 断连"] --> B{"原因定位"}
- B -->|网络不通| C["检查防火墙 / 安全组端口"]
- B -->|Binlog 已过期| D["purge binary logs / 调整 expire_logs_days"]
- B -->|认证失败| E["核对 user 权限 & password"]
- B -->|Server UUID 冲突| F["重置 slave server_uuid"]
- C --> G["CHANGE REPLICATION SOURCE TO
SOURCE_LOG_FILE = '...',
SOURCE_LOG_POS = ..."]
+ B -->|"网络不通"| C["检查防火墙和安全组端口"]
+ B -->|"Binlog 已过期"| D["purge binary logs"]
+ B -->|"认证失败"| E["核对 user 权限和 password"]
+ B -->|"Server UUID 冲突"| F["重置 slave server_uuid"]
+ C --> G["CHANGE REPLICATION SOURCE TO"]
D --> G
E --> G
F --> G
@@ -313,7 +375,7 @@ SHOW MASTER LOGS;
这通常是由于数据不一致导致的——例如从库被手动修改过。
-> [!WARNING] 不要直接跳过！
+> [!warning] 不要直接跳过！
> 盲目 `sql_slave_skip_counter` 可能导致数据静默丢失。必须先确认事务内容。
```sql
@@ -322,13 +384,14 @@ SHOW MASTER LOGS;
-- STOP SLAVE; START SLAVE;
-- ✅ MySQL 8.0+ GTID 模式：跳过指定事务
-SET GTID_NEXT='3E11FA47-71CA-11E1-9E33-C80AA9429562:100';
-BEGIN; COMMIT;
-SET GTID_NEXT='AUTOMATIC';
+-- 核心思路：假装已经执行过这个事务，让从库跳过它
+SET GTID_NEXT='3E11FA47-71CA-11E1-9E33-C80AA9429562:100'; -- 指定要跳过的 GTID
+BEGIN; COMMIT; -- 提交一个空事务, 标记该 GTID 为已执行
+SET GTID_NEXT='AUTOMATIC'; -- 恢复自动分配 GTID
--- 重新加入复制组
+-- 如果需要从头重建从库的 GTID 记录（慎用！）
STOP REPLICA;
-SET GLOBAL gtid_purged = '3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100';
+SET GLOBAL gtid_purged = '3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100'; -- 声明从库已拥有这些 GTID
START REPLICA;
```
@@ -336,10 +399,10 @@ START REPLICA;
```mermaid
flowchart LR
- A["Seconds_Behind_Master 大"] --> B{"IO 延迟还是 SQL 延迟?"}
- B -->|"Relay_Log_Space 持续增长"| C["SQL Worker 回放太慢
→ 增加 replica_parallel_workers
→ 考虑 GROUP_TRANSACTIONS"]
- B -->|"Read_Master_Log_Pos 跟丢"| D["网络带宽不足 / Master
写入量太大
→ 检查网络 / 限制 binlog 传输大小"]
- B -->|"DDL 执行中"| E["大表 ALTER TABLE 阻塞
→ 使用 pt-online-schema-change"]
+ A["Seconds_Behind_Master 大"] --> B{"IO 延迟还是 SQL 延迟"}
+ B -->|"Relay_Log_Space 持续增长"| C["SQL Worker 回放太慢, 增加 replica_parallel_workers"]
+ B -->|"Read_Master_Log_Pos 跟丢"| D["网络带宽不足或 Master 写入量太大"]
+ B -->|"DDL 执行中"| E["大表 ALTER TABLE 阻塞, 使用 pt-online-schema-change"]
style C fill:#00B6BC,color:#fff
style D fill:#FF9F43,color:#000
diff --git a/hhs/MySQL/08-工程实践/37-分库分表.md b/hhs/MySQL/08-工程实践/37-分库分表.md
index 2aaf467..cdb7147 100644
--- a/hhs/MySQL/08-工程实践/37-分库分表.md
+++ b/hhs/MySQL/08-工程实践/37-分库分表.md
@@ -7,7 +7,9 @@ create time: 2026-05-16 00:00
## 概述
-当单库单表的百万级数据无法满足性能需求时，分库分表（Sharding）成为必选方案。但分片不仅是技术决策，更是业务架构的改变——它引入了跨分片查询、分布式 ID、数据重平衡等一系列新问题。
+想象你开了一家超市，所有商品都放在一个仓库里。当商品只有几千种时，一个仓库绰绰有余；但当商品增长到几十万种，一个仓库就变得拥挤不堪——找货慢、入库堵、仓库还会塌。解决方案很简单：**建多个仓库，按规则分配商品**。这就是分库分表（Sharding）的核心思想。
+
+当单库单表的数据量超出 MySQL 的舒适区时，分库分表成为必选方案。但分片不仅是技术决策，更是业务架构的改变——它引入了跨分片查询、分布式 ID、数据重平衡等一系列新问题，每一个都是对团队工程能力的考验。
> [!QUESTION] 你真的需要分库分表吗？
>
@@ -36,12 +38,12 @@ flowchart TD
style V1 fill:#00B6BC,color:#fff
```
-| 维度 | 适用场景 | 优点 | 缺点 |
-|------|---------|------|------|
-| **Hash 分片** | 均匀写入分散压力 | 数据分布均匀 | 范围查询需遍历所有分片 |
-| **Range 分片** | 时间序列、归档场景 | 天然支持范围查询 | 热点数据倾斜（双 11） |
-| **List 分片** | 租户隔离、地域隔离 | 边界清晰、易于运维 | 新增分区需预规划 |
-| **垂直拆分** | 多业务混合负载 | 业务解耦、故障隔离 | 跨库 JOIN 变复杂 |
+| 维度 | 类比 | 适用场景 | 优点 | 缺点 |
+|------|------|---------|------|------|
+| **Hash 分片** | 按姓名首字母分班 | 均匀写入、分散压力 | 数据分布均匀 | 范围查询需遍历所有分片 |
+| **Range 分片** | 按年份归档文件 | 时间序列、归档场景 | 天然支持范围查询 | 热点数据倾斜（如双 11） |
+| **List 分片** | 按部门分配办公区 | 租户隔离、地域隔离 | 边界清晰、易于运维 | 新增分区需提前规划 |
+| **垂直拆分** | 超市按品类分区 | 多业务混合负载 | 业务解耦、故障隔离 | 跨库 JOIN 变复杂 |
> [!TIP] 最佳实践：先垂直再水平
> 如果不同业务的表耦合在同一库里，先做**垂直拆分**（按业务域拆成多个库），再对单个大表做**水平拆分**。两步都做能最大化收益。
@@ -68,42 +70,104 @@ func GetShardTableName(orderID int64, shardCount int) string {
### Range 分片
-```sql
--- 按月分表（适合审计日志、交易流水等时间序列数据）
--- logs_202601, logs_202602, ..., logs_202612
--- 优势：天然支持范围查询 WHERE created_at BETWEEN ...
--- 劣势：最近月份写入压力大，历史月份只有读取
-```
+Range 分片的核心思想是**按连续区间划分**，最典型的场景就是按时间分表——每个月一张表，就像把文件按年份放进不同的文件夹。
```sql
--- 利用 range 分片的特性做数据归档
--- 每月 1 号自动将上月数据迁移到 archive 库
-ALTER TABLE logs_202601 RENAME TO archive.logs_202601_old;
-CREATE TABLE logs_202602 LIKE logs_202601;
+-- 按月分表：审计日志、交易流水等时间序列数据
+-- 表名：logs_202601, logs_202602, ..., logs_202612
+
+-- 查询某月数据 → 只需访问一张表
+SELECT * FROM logs_202603 WHERE level = 'ERROR' ORDER BY created_at DESC LIMIT 100;
+
+-- 跨月范围查询 → 路由层自动合并多张表
+SELECT * FROM logs_202603
+UNION ALL
+SELECT * FROM logs_202604
+WHERE created_at BETWEEN '2026-03-01' AND '2026-04-30';
```
+```go
+// 路由层：根据时间范围计算需要查询哪些表
+func GetLogTableNames(start, end time.Time) []string {
+ var tables []string
+ for t := start; !t.After(end); t = t.AddDate(0, 1, 0) {
+ tables = append(tables, fmt.Sprintf("logs_%s", t.Format("200601")))
+ }
+ return tables
+}
+```
+
+> [!TIP] Range 分片天然适合做数据归档
+> 历史数据可以直接迁移到低成本存储，操作极其简单：
+> ```sql
+> -- 将上月数据归档到 archive 库，腾出 SSD 空间
+> ALTER TABLE logs_202601 RENAME TO archive.logs_202601_old;
+> -- 为下月预创建空表
+> CREATE TABLE logs_202602 LIKE logs_202601;
+> ```
+
+> [!QUESTION] Range 分片最大的风险是什么？
+> 答：**数据倾斜**。如果你按月分表，双 11 当天的写入量可能是平时的 100 倍——所有的写入压力集中在一张表上。解决方案：对热点时段做二次 Hash 分片（见下方"联合分片"）。
+
### List 分片
+List 分片是**按枚举值分组**，最典型的场景是 SaaS 多租户——每个租户的数据天然隔离，互不干扰。就像办公楼按公司分配楼层，A 公司在 3 楼，B 公司在 5 楼。
+
```sql
--- 按 tenant_id 列表拆分（SaaS 多租户场景）
--- tenant_A 的所有表在一个库，tenant_B 在另一个库
--- 优势：租户级别的数据隔离，方便合规审查
--- tenant_A: db_tenant_0.tenant_A_users, db_tenant_0.tenant_A_orders
--- tenant_B: db_tenant_1.tenant_B_users, db_tenant_1.tenant_B_orders
+-- SaaS 多租户场景：每个租户的数据在独立的库中
+-- tenant_A: db_tenant_0.orders, db_tenant_0.users
+-- tenant_B: db_tenant_1.orders, db_tenant_1.users
+
+-- 查询时自动路由到对应库
+-- 应用层根据 tenant_id 选择数据库连接
+SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC;
+-- → tenant_A 走 db_tenant_0，tenant_B 走 db_tenant_1
```
+```go
+// 路由层：根据租户 ID 选择目标数据库
+func GetTenantDB(tenantID string) *sql.DB {
+ // 租户 → 库的映射关系（可存配置中心或 Redis）
+ dbMap := map[string]*sql.DB{
+ "tenant_A": dbTenant0,
+ "tenant_B": dbTenant1,
+ }
+ return dbMap[tenantID]
+}
+```
+
+> [!NOTE] List 分片的额外好处：合规审计
+> 某些行业（金融、医疗）要求租户数据物理隔离。List 分片天然满足这一需求——不同租户的数据在不同物理库中，审计时只需检查对应库即可。
+
### 联合分片
-```sql
--- 双维度分片：shard_id = (user_id % 16) * 4 + (month % 4)
--- 第一层 user_id 哈希：分散写入压力，同一用户的记录集中
--- 第二层 month 取模：便于按时间范围和归档
--- 共 16 × 4 = 64 张子表
+单一维度的分片总有局限：Hash 分片不支持范围查询，Range 分片会数据倾斜。**联合分片是两种策略的组合**——用两个（或更多）维度共同决定数据归属。
+
+```go
+// 联合分片公式：shard_id = (user_id % 16) * 4 + (month % 4)
+// 第一层 user_id % 16 → 分散写入压力，同一用户的数据集中
+// 第二层 month % 4 → 按时间归档，热点月份自动分散到 4 张表
+// 共 16 × 4 = 64 张子表
+
+func GetShardTableName(userID int64, t time.Time) string {
+ userShard := userID % 16 // 用户维度：16 个桶
+ timeShard := int(t.Month()-1) % 4 // 时间维度：4 个桶
+ shardID := userShard*4 + int64(timeShard)
+ return fmt.Sprintf("orders_%d", shardID)
+}
+
+// 举例：
+// user_id=1001, 2026年3月 → orders_38 (1001%16=9, month=2, 9*4+2=38)
+// user_id=1001, 2026年5月 → orders_36 (1001%16=9, month=4, 9*4+0=36)
+// user_id=2002, 2026年3月 → orders_10 (2002%16=2, month=2, 2*4+2=10)
+// 同一用户不同月份的数据落在相邻分片，方便按用户维度聚合
```
## 分片键选型指南
-分片键是选择最关键的决策——**一旦选定，后期几乎无法更换**。
+分片键（Sharding Key）是分库分表中最关键的决策——**一旦选定，后期几乎无法更换**。选错了分片键，就像把图书馆的书按"书名首字"分区，找"数据库"相关的书要跑遍 20 个书架。
+
+分片键的核心要求只有一个：**让最常用的查询能精确定位到一个分片**，而不是扫描所有分片。
```mermaid
flowchart TD
@@ -151,7 +215,7 @@ flowchart TD
## 分布式 ID 与分片的关系
-分库分表后，**全局唯一 ID** 是第一道门槛。每个分片的自增 ID 只在本地有意义，合并时必然冲突。
+分库分表后，**全局唯一 ID** 是第一道门槛。想象有两个班级各自编号：A 班有 1 号、2 号、3 号……B 班也有 1 号、2 号、3 号……当两个班级合并参加运动会时，"1 号"到底是谁？这就是分库后自增 ID 冲突的问题。
> [!IMPORTANT] 主键策略必须适配分片
>
@@ -169,15 +233,18 @@ flowchart TD
## 跨分片查询
-这是分库分表最大的痛点。
+这是分库分表最大的痛点。分片前，一个 `JOIN` 就能搞定的查询，分片后可能需要遍历所有分片再手动合并。
### 不可行方案
```sql
--- ❌ JOIN 跨分片：MySQL 原生不支持分布式 JOIN
--- 一个表在 sharded_db.orders_0..3，另一个在 user_db.users
+-- ❌ 跨分片 JOIN：MySQL 的 JOIN 只在同一实例内有效
+-- orders 表在 sharded_db，users 表在 user_db，两个不同的实例
+-- 这条 SQL 会直接报错：Table 'user_db.users' doesn't exist
+SELECT o.*, u.name FROM orders o JOIN users u ON o.user_id = u.id;
--- ❌ UNION ALL 拼全部分片（除非你知道具体分片号）
+-- ❌ 暴力 UNION ALL：除非你能精确计算分片号，否则必须扫描全部分片
+-- 4 个分片还好，如果有 64 个分片，每次都扫全量就太浪费了
SELECT * FROM orders_0 WHERE user_id = 100
UNION ALL SELECT * FROM orders_1 WHERE user_id = 100
UNION ALL SELECT * FROM orders_2 WHERE user_id = 100
@@ -243,78 +310,99 @@ flowchart LR
```
```go
-// 游标分页 + 多路归并排序
-// 类似 Git rebase 的多分支合并逻辑
+// 核心思路：游标分页 + 多路归并
+// 第一步：每个分片多取一些数据（扩大缓冲区）
+// 第二步：应用层合并所有结果，排序后截取需要的条数
type PageRequest struct {
UserID int64
- Limit int // 期望返回数量
- AfterTs int64 // 游标：上次最后一条的时间戳
+ Limit int // 期望返回条数，比如 20
+ AfterTs int64 // 游标：上一页最后一条的时间戳，首次请求传 0
}
func QueryShardedOrders(req PageRequest) ([]Order, error) {
- shards := []string{fmt.Sprintf("orders_%d", req.UserID%4)}
+ // 1. 计算目标分片（这里只查 1 个分片，因为 user_id % 4 路由精确）
+ shard := fmt.Sprintf("orders_%d", req.UserID%4)
- // Step 1: 各分片拉取 (Limit + Depth) 条数据
- type RawPage struct {
- Shard string
- Orders []Order
+ // 2. 扩大窗口：请求 20 条，但从每个分片取 40 条作为缓冲
+ // 为什么要多取？因为游标边界附近的数据可能分布在不同分片
+ bufferSize := req.Limit * 2
+ query := fmt.Sprintf(
+ "SELECT * FROM %s WHERE user_id = %d AND created_at < %d ORDER BY created_at DESC LIMIT %d",
+ shard, req.UserID, req.AfterTs, bufferSize,
+ )
+ rows, _ := db.Query(getConn(shard), query)
+ orders := scanOrders(rows)
+
+ // 3. 截取需要的数量
+ if len(orders) > req.Limit {
+ orders = orders[:req.Limit]
}
-
- var allPages []RawPage
- for _, shard := range shards {
- q := fmt.Sprintf(
- "SELECT * FROM %s WHERE user_id = %d AND created_at < %d ORDER BY created_at DESC LIMIT %d",
- shard, req.UserID, req.AfterTs, req.Limit*2, // 扩大 2 倍缓冲
- )
- rows, _ := db.Query(shardDBConn(shard), q)
- orders := scanOrders(rows)
- allPages = append(allPages, RawPage{shard, orders})
- }
-
- // Step 2: 多路归并（k-way merge）
- merged := mergeSort(allPages, req.Limit)
- return merged, nil
+ return orders, nil
}
-// k-way merge：类似归并排序的 merge 步骤
-func mergeSort(pages []RawPage, limit int) []Order {
- all := make([]Order, 0, len(pages)*limit)
- for _, p := range pages {
- all = append(all, p.Orders...)
+// 当分片键不是查询条件时（比如按时间全局排序），需要扫描所有分片：
+func QueryAllShards(req PageRequest) ([]Order, error) {
+ var allOrders []Order
+ for i := 0; i < 4; i++ {
+ shard := fmt.Sprintf("orders_%d", i)
+ query := fmt.Sprintf(
+ "SELECT * FROM %s WHERE created_at < %d ORDER BY created_at DESC LIMIT %d",
+ shard, req.AfterTs, req.Limit*2,
+ )
+ rows, _ := db.Query(getConn(shard), query)
+ allOrders = append(allOrders, scanOrders(rows)...)
}
- sort.Slice(all, func(i, j int) bool {
- return all[i].CreatedAt.After(all[j].CreatedAt)
+
+ // 全局排序 + 截取
+ sort.Slice(allOrders, func(i, j int) bool {
+ return allOrders[i].CreatedAt.After(allOrders[j].CreatedAt)
})
- if len(all) > limit {
- return all[:limit]
+ if len(allOrders) > req.Limit {
+ allOrders = allOrders[:req.Limit]
}
- return all
+ return allOrders, nil
}
```
> [!QUESTION] 为什么不在数据库层做多分片聚合？
-> 因为每个分片上的 `LIMIT` 只在自己分片范围内有效。想象你有 4 个桶，每个桶倒出前 20 颗珠子，合起来 80 颗里取前 20——但如果你要的是「全局第 1000~1020 颗」，每个桶自己取前 20 完全不够。**解决方案是加大每片采集窗口，然后在应用层做全局排序截断。** 代价是内存和延迟增加，但这是分布式系统的固有 Trade-off。
+> 因为每个分片上的 `LIMIT` 只在自己分片范围内有效。举个具体例子：你有 4 个分片，想查全局第 100~120 条数据。如果每个分片执行 `LIMIT 100, 20`，得到的是"每个分片自己排第 100~120 条"——合起来 80 条数据，但它们和全局第 100~120 条完全不同。
+>
+> **正确做法**：从每个分片多取一些数据（扩大窗口），在应用层做全局排序后截取。代价是内存和延迟增加，但这是分布式系统的固有 Trade-off。
### 跨分片聚合（COUNT / SUM / AVG）
-```sql
--- ❌ COUNT(*) 在单个分片运行，汇总时直接相加即可
--- ✅ 聚合类查询：SUM(xxx) → 各分片算完再 SUM
+简单聚合（COUNT、SUM、AVG）的思路很直接：**每个分片各自算一遍，应用层再合并**。比如总订单数 = 分片 0 的 COUNT + 分片 1 的 COUNT + ……
--- 但复杂聚合（GROUP BY + JOIN）会很贵
--- 方案：预计算 + 定时汇总表
--- cron 每小时执行一次：
+但 `GROUP BY + 聚合` 就麻烦了——你需要合并各分片的分组结果，逻辑复杂且性能差。**更好的方案是预计算**：
+
+```sql
+-- 方案：定时汇总表（cron 每小时执行一次）
+-- 每个分片各自聚合，结果写入同一张汇总表
INSERT INTO summary_daily (date, total_orders, total_amount)
SELECT DATE(created_at), COUNT(*), SUM(amount)
FROM orders_0 GROUP BY DATE(created_at)
UNION ALL
SELECT DATE(created_at), COUNT(*), SUM(amount)
-FROM orders_1 GROUP BY DATE(created_at);
+FROM orders_1 GROUP BY DATE(created_at)
+UNION ALL
+SELECT DATE(created_at), COUNT(*), SUM(amount)
+FROM orders_2 GROUP BY DATE(created_at)
+UNION ALL
+SELECT DATE(created_at), COUNT(*), SUM(amount)
+FROM orders_3 GROUP BY DATE(created_at);
+
+-- 查询时直接读汇总表，响应速度从"秒级"降到"毫秒级"
+SELECT date, SUM(total_orders), SUM(total_amount)
+FROM summary_daily
+WHERE date BETWEEN '2026-05-01' AND '2026-05-31'
+GROUP BY date;
```
## 中间件方案
+前面的代码示例都是手动计算分片路由——在生产环境中，我们更常用成熟的中间件来处理分片逻辑。中间件就像一个"智能路由器"：应用发一条普通 SQL，中间件自动帮你拆分、路由、合并结果。
+
| 中间件 | 开发者 | 部署模式 | 核心特点 |
|--------|-------|---------|---------|
| **Vitess** | YouTube / Google | Proxy | 透明分片、在线 Re-sharding、K8s 原生 |
@@ -363,6 +451,8 @@ flowchart TB
### 双写迁移法（推荐）
+双写迁移的思路很直观：**新旧两套库同时写入，逐步切换读流量**。就像搬新家时，先把旧家具搬到新房子，同时新旧两个地址都收快递——等新家收拾好了，再把快递地址改成新家。
+
```mermaid
flowchart TD
A["旧库 single_db"] --> B["新集群 sharded_db_0..N"]
@@ -408,21 +498,37 @@ func CreateOrder(order *Order) error {
### 渐进式迁移（适合超大表）
+渐进式迁移的核心思想是**分批切换**——先迁移一部分流量到新集群，验证无误后再迁移下一批，最终全部切完。就像搬办公室：先把一个部门搬过去，安顿好了再搬下一个，而不是一次性把整层楼的人都搬走。
+
+```mermaid
+flowchart LR
+ subgraph Init["初始状态"]
+ AllOld["全部流量"] --> OldDB["老库"]
+ end
+
+ subgraph P1["Phase 1: 50% 流量"]
+ P1Even["hash(user_id) % 2 == 0"] --> NewS01["新分片 0,1"]
+ P1Odd["hash(user_id) % 2 == 1"] --> OldDB2["老库"]
+ end
+
+ subgraph P2["Phase 2: 100% 流量"]
+ P2A["hash(user_id) % 4 == 0,1"] --> NewS01B["新分片 0,1"]
+ P2B["hash(user_id) % 4 == 2,3"] --> NewS23["新分片 2,3"]
+ end
+
+ Init -->|"Phase 1: 先切一半"| P1
+ P1 -->|"Phase 2: 再切剩余"| P2
+
+ style P1 fill:#FFEAA7,color:#000
+ style P2 fill:#00D866,color:#fff
```
-┌──────────────────────────────────────────────────┐
-│ 渐进式迁移：按分片逐步切换 │
-│ │
-│ 初始: 全部流量 → 老库 │
-│ Phase 1: hash(user_id) % 2 == 0 → 新分片 0,1 │
-│ hash(user_id) % 2 == 1 → 老库 │
-│ Phase 2: hash(user_id) % 4 = 0,1 → 新分片 0,1 │
-│ hash(user_id) % 4 = 2,3 → 新分片 2,3 │
-│ Final: 全部流量 → 新集群 │
-│ │
-│ 优势：每次切换只影响部分用户，风险可控 │
-│ 劣势：需要在应用层维护两套路由规则 │
-└──────────────────────────────────────────────────┘
-```
+
+> [!TIP] 渐进式迁移的核心优势
+> - **风险可控**：每次只影响部分用户，出问题时只需回滚那部分流量
+> - **可灰度验证**：先选一小批内部用户试跑，确认无误后再扩大范围
+> - **无需停机**：整个过程对用户透明，业务零感知
+>
+> 劣势：需要在应用层维护两套路由规则，增加了代码复杂度。
> [!WARNING] 迁移 checklist
>
@@ -434,14 +540,16 @@ func CreateOrder(order *Order) error {
## 分片的挑战与反模式
-| 问题 | 描述 | 应对策略 |
-|------|------|---------|
-| **数据倾斜** | 某些分片数据量远大于其他 | 检查 hash 分布，必要时换分片键或加 salt |
-| **跨分片事务** | InnoDB 不支持跨库事务 | 用 Saga / TCC / 消息队列补偿 |
-| **Rebalance** | 新增节点后数据如何迁移 | 渐进式迁移，Vitess 内置 Scatter-Gather |
-| **复杂聚合** | COUNT / SUM 跨分片很贵 | 预计算 + 定时汇总到汇总表 |
-| **分页困难** | LIMIT 深分页在各分片各自生效 | 游标分页 + 应用层合并（见上方详解） |
-| **全局唯一约束** | UNIQUE KEY 在多分片下失效 | 改为业务层面去重，或用 Redis SET |
+分库分表不是银弹，它解决了一个问题，却引入了更多问题。下表列出了最常见的"坑"和应对策略：
+
+| 问题 | 具体表现 | 应对策略 |
+|------|---------|---------|
+| **数据倾斜** | 某些分片数据量远大于其他（比如大卖家的订单集中在某个分片） | 检查 hash 分布，必要时换分片键或加 salt 打散 |
+| **跨分片事务** | 一笔业务涉及多个分片，InnoDB 不支持跨库事务 | 用 Saga / TCC / 消息队列补偿（见 [[hhs/MySQL/08-工程实践/36-分布式事务]]) |
+| **Rebalance** | 新增节点后，老数据如何迁移到新分片？ | 渐进式迁移，Vitess 内置 Scatter-Gather |
+| **复杂聚合** | COUNT / SUM 跨分片很贵，GROUP BY 更是噩梦 | 预计算 + 定时汇总到汇总表（见上方详解） |
+| **分页困难** | LIMIT 深分页在各分片各自生效，合并后结果不对 | 游标分页 + 应用层合并（见上方详解） |
+| **全局唯一约束** | UNIQUE KEY 在多分片下失效（两个分片可能各插入同一条） | 改为业务层面去重，或用 Redis SET |
> [!WARNING] 别过早分片
>