Init
This commit is contained in:
@@ -0,0 +1,347 @@
|
||||
---
|
||||
tags: [MySQL, 范式, 表设计, 反范式]
|
||||
create time: 2026-05-16 12:56
|
||||
---
|
||||
|
||||
# 表结构设计三范式
|
||||
|
||||
## 概述
|
||||
|
||||
> [!abstract] 本文内容
|
||||
> 1. **三大范式**：从 1NF 到 3NF，理解为什么需要拆分表
|
||||
> 2. **BCNF 简介**：何时需要更进一步
|
||||
> 3. **范式化 vs 反范式化**：理论与实践的权衡
|
||||
> 4. **设计流程**：一套可操作的建表步骤
|
||||
|
||||
数据库设计的规范化理论是避免数据冗余和更新异常的基石。但教科书里的完美范式落到工程实际中往往要打折——过度规范化会导致七表 JOIN、查询慢如蜗牛；完全抛弃规范又会让数据变成一盘散沙。
|
||||
|
||||
本节的目标不是背定义，而是建立一套**可操作的设计直觉**：什么时候该拆，什么时候该合。
|
||||
|
||||
> [!QUESTION] 思考：如果有一张订单表，字段包括 `order_id`, `user_name`, `user_dept`, `product_name`, `product_category`, `quantity`, `total`——这张表有几种范式违规？分别是什么？
|
||||
> （带着这个问题读完本文，你会找到答案。）
|
||||
|
||||
## 三大范式
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
F1["1NF: 原子性"] --> F2["2NF: 消除部分依赖"]
|
||||
F2 --> F3["3NF: 消除传递依赖"]
|
||||
|
||||
style F1 fill:#00B6BC,color:#fff
|
||||
style F2 fill:#FF9F43,color:#000
|
||||
style F3 fill:#C44569,color:#fff
|
||||
```
|
||||
|
||||
### 第一范式（1NF）—— 列不可再分
|
||||
|
||||
```sql
|
||||
-- ✅ 满足 1NF：每个单元格只有一个值
|
||||
CREATE TABLE employees (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
name VARCHAR(100),
|
||||
phone VARCHAR(20), -- 单一手机号
|
||||
skills JSON -- 数组存在 JSON 字段内（如 ["Go","Python"]）
|
||||
);
|
||||
|
||||
-- ❌ 违反 1NF：同一列存多个值（用逗号分隔）
|
||||
CREATE TABLE bad_employees (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
name VARCHAR(100),
|
||||
skills VARCHAR(255) -- 'Go,Python,Docker' — 不行！无法单独查询某个技能
|
||||
);
|
||||
```
|
||||
|
||||
> [!TIP] 现代变通方案
|
||||
>
|
||||
> MySQL 5.7+ 支持 JSON 类型。虽然从严格范式角度看 JSON 列内部仍有复合结构，但数据库引擎提供了高效的索引和查询能力（如 `JSON_EXTRACT`），所以在工程实践中被广泛接受。**核心原则不变：不要把非结构化数据当字符串拼接处理。**
|
||||
|
||||
1NF 是最基本的要求——每一列都是原子值，不能再拆分。现代关系型数据库默认强制执行 1NF。
|
||||
|
||||
### 第二范式（2NF）—— 消除部分函数依赖
|
||||
|
||||
> **前提**：先满足 1NF。2NF 主要针对复合主键的情况。
|
||||
|
||||
```sql
|
||||
-- ❌ 违反 2NF：订单明细表中，商品名只依赖 commodity_id，不完全依赖 (order_id, commodity_id)
|
||||
CREATE TABLE order_items_bad (
|
||||
order_id BIGINT,
|
||||
commodity_id BIGINT,
|
||||
commodity_name VARCHAR(200), -- 只依赖 commodity_id
|
||||
quantity INT, -- 依赖 (order_id, commodity_id)
|
||||
PRIMARY KEY (order_id, commodity_id)
|
||||
);
|
||||
|
||||
-- ✅ 修正：拆分出去
|
||||
CREATE TABLE commodities (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
name VARCHAR(200) NOT NULL
|
||||
);
|
||||
|
||||
CREATE TABLE order_items (
|
||||
order_id BIGINT,
|
||||
commodity_id BIGINT,
|
||||
quantity INT,
|
||||
PRIMARY KEY (order_id, commodity_id),
|
||||
FOREIGN KEY (commodity_id) REFERENCES commodities(id)
|
||||
);
|
||||
```
|
||||
|
||||
> [!TIP] 实战建议
|
||||
> 如果你用的主键都是单列自增 ID（而非复合主键），那么 2NF 的要求自动满足——因为没有"部分依赖"的问题。现代设计中几乎不用复合主键，所以 2NF 在实践中很少成为约束。
|
||||
|
||||
### 第三范式（3NF）—— 消除传递依赖
|
||||
|
||||
> **核心原则**：非主键列之间不能有依赖关系。即"非主属性不依赖于其他非主属性"。
|
||||
|
||||
```sql
|
||||
-- ❌ 违反 3NF：在商品表中，city 通过 area_code 间接依赖于 id
|
||||
-- id → area_code → city（传递依赖）
|
||||
CREATE TABLE products_bad (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
name VARCHAR(200),
|
||||
area_code INT, -- 区号
|
||||
city VARCHAR(50) -- 城市：由 area_code 决定，不是直接由 id 决定
|
||||
);
|
||||
|
||||
-- ✅ 修正：拆成两张表
|
||||
CREATE TABLE areas (
|
||||
area_code INT PRIMARY KEY,
|
||||
city VARCHAR(50) NOT NULL
|
||||
);
|
||||
|
||||
CREATE TABLE products (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
name VARCHAR(200),
|
||||
area_code INT,
|
||||
FOREIGN KEY (area_code) REFERENCES areas(area_code)
|
||||
);
|
||||
```
|
||||
|
||||
> [!TIP] 直觉判断法
|
||||
> 读一下这些字段："商品的**城市**是通过什么决定的？"如果你发现是"通过**区号**决定的"，而不是直接通过商品本身决定——那就是传递依赖，需要拆分。
|
||||
>
|
||||
> 对比 2NF：2NF 问的是"这列依赖主键的**全部**吗？"；3NF 问的是"这列有没有**绕道**经过另一列？"
|
||||
|
||||
#### BCNF（修正的第三范式）
|
||||
|
||||
BCNF 比 3NF 更严格：**任何非平凡函数依赖的决定因素必须是超键**。
|
||||
|
||||
```sql
|
||||
-- 一个典型的 BCNF 违规场景
|
||||
-- 学生选课表：(学生, 课程) → 成绩；教师 → 课程
|
||||
CREATE TABLE student_course_teachers (
|
||||
student_id BIGINT,
|
||||
course_id BIGINT,
|
||||
teacher_id BIGINT, -- 教师只依赖课程，不完全依赖复合主键
|
||||
grade DECIMAL(5, 2),
|
||||
PRIMARY KEY (student_id, course_id)
|
||||
);
|
||||
```
|
||||
|
||||
```sql
|
||||
-- ✅ 修正为 BCNF：拆成两张表，让每个决定因素都是超键
|
||||
CREATE TABLE courses_teachers (
|
||||
course_id BIGINT PRIMARY KEY,
|
||||
teacher_id BIGINT NOT NULL,
|
||||
UNIQUE KEY uk_course (course_id) -- 一门课只有一位老师
|
||||
);
|
||||
|
||||
CREATE TABLE student_grades (
|
||||
student_id BIGINT,
|
||||
course_id BIGINT,
|
||||
grade DECIMAL(5, 2),
|
||||
PRIMARY KEY (student_id, course_id),
|
||||
FOREIGN KEY (course_id) REFERENCES courses_teachers(course_id)
|
||||
);
|
||||
```
|
||||
|
||||
> [!QUESTION] 3NF 已经够了，为什么还需要 BCNF？
|
||||
>
|
||||
> 大多数工程场景 3NF 完全够用。BCNF 解决的问题通常涉及**多重候选键重叠**的复杂建模。如果你遇到 "一门课只能由一位老师教" 这样的约束，且该约束与你的自然主键冲突，才需要考虑 BCNF。实践中建议先做到 3NF，遇到更新异常再往上走。
|
||||
|
||||
> [!WARNING] 关于 MySQL 自增主键的陷阱
|
||||
> 给所有表加上 `id BIGINT AUTO_INCREMENT` 后，从理论上讲每个表的函数依赖都变成了「所有列直接依赖主键」——**自增 ID 会掩盖范式设计缺陷**。
|
||||
>
|
||||
> 但这恰恰是现代工程实践的真相：我们用自增代理主键保证查询性能，用外键语义保证设计合理。**范式检查应该在业务层（逻辑模型）上做，而不是在物理表结构上硬抠。**
|
||||
|
||||
## 三范式速查总结
|
||||
|
||||
读完上面的详细内容，回头用这张表做最后的对比和记忆强化：
|
||||
|
||||
| 范式 | 核心问题 | 违规症状 | 一句话修复 |
|
||||
|------|---------|---------|-----------|
|
||||
| **1NF** | 列是不是原子值？ | 一格里塞了多个值 | 拆成多行或多列 |
|
||||
| **2NF** | 这列依赖主键的**全部**吗？（仅复合 PK 场景） | 某些列只依赖主键的一部分 | 把只依赖部分的列拆到新表 |
|
||||
| **3NF** | 这列有没有**绕道**经过其他非主键列？ | B 列的值由 C 列决定，而不是直接由主键决定 | 把 C 列及它决定的所有列拆出去 |
|
||||
| **BCNF** | 每个决定因素都是超键吗？ | 候选键之间有重叠，约束冲突 | 拆到没有交叉候选键为止 |
|
||||
|
||||
---
|
||||
|
||||
## 表设计实操流程
|
||||
|
||||
知道范式定义是一回事，拿到需求画出一张合理的 ER 图是另一回事。这里给一个**四步工作流**：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["1. 列清单<br/>把所有需要的字段写下来"] --> B["2. 定主键<br/>自然 PK or 代理 PK?"]
|
||||
B --> C["3. 检查依赖<br/>每列是否直接依赖主键?"]
|
||||
C -->|"否"| D["拆表 + FK 关联"]
|
||||
D --> E["4. 审视 JOIN<br/>有没有过度拆分?"]
|
||||
E --> F["✅ 完成"]
|
||||
E -->|"JOIN 过多"| G["考虑反范式化"]
|
||||
G --> F
|
||||
```
|
||||
|
||||
### Step 1：列出所有需要的字段
|
||||
|
||||
不要一上来就想"分几张表"。先像产品经理一样列出这张实体需要的所有属性。
|
||||
|
||||
```
|
||||
订单：下单时间、用户ID、收货地址、商品名称、商品数量、总价、优惠券、实际支付金额...
|
||||
```
|
||||
|
||||
### Step 2：确定主键
|
||||
|
||||
| 选择 | 适用场景 | 例子 |
|
||||
|------|---------|------|
|
||||
| **自然主键**（业务唯一标识） | 有天然且不变的唯一码 | 身份证号、ISO 国家代码 |
|
||||
| **代理主键**（推荐默认选项） | 大多数业务场景 | `BIGINT AUTO_INCREMENT` / `UUID` |
|
||||
|
||||
> [!TIP] 默认选代理主键（自增 BIGINT），除非你有明确的理由不用它。这是 95% 项目的最佳起点。
|
||||
|
||||
### Step 3：逐个检查函数依赖
|
||||
|
||||
对每一列问两个问题：
|
||||
1. **它依赖主键的全部吗？** → 不依赖 = 违反 2NF → 拆出去
|
||||
2. **它绕道经过其他非主键列吗？** → 有传递依赖 = 违反 3NF → 拆出去
|
||||
|
||||
### Step 4：审视 JOIN 成本
|
||||
|
||||
把表都拆完后，回到你最常用的那条查询，估算需要几个 JOIN。超过 3~4 个的话，认真考虑**局部反范式化**——在目标表中冗余关键信息，而非为了一条查询拆回去。
|
||||
|
||||
## 范式化的代价
|
||||
|
||||
> [!QUOTE] 范式设计的目的不是追求完美，而是找到合适的平衡点。
|
||||
|
||||
过度范式化的直接后果就是 **JOIN 爆炸**。每多一张表就多一次磁盘随机读、一个锁竞争点、一条复杂执行计划：
|
||||
|
||||
```sql
|
||||
-- 7 张表 JOIN 才能拿到订单完整信息...
|
||||
SELECT o.id, u.name, u.dept, c.cat_name, p.brand, sh.city, pg.payment_type
|
||||
FROM orders o
|
||||
JOIN users u ON o.user_id = u.id
|
||||
JOIN departments d ON u.dept_id = d.id
|
||||
JOIN categories c ON o.category_id = c.id
|
||||
JOIN products p ON o.product_id = p.id
|
||||
JOIN shipments sh ON o.shipment_id = sh.id
|
||||
JOIN payments pg ON o.payment_id = pg.id
|
||||
WHERE o.id = 1;
|
||||
```
|
||||
|
||||
> [!TIP] 经验法则
|
||||
> - **单个查询 ≤ 3 个 JOIN**：没问题，规范化设计是合理的
|
||||
> - **4~6 个 JOIN**：开始警惕，检查是否所有关联都是必要的
|
||||
> - **> 6 个 JOIN**：几乎可以确定需要局部反范式化
|
||||
>
|
||||
> 用 `EXPLAIN` 看看实际执行计划——`Using temporary` + `Using filesort` 是性能杀手。
|
||||
|
||||
## 反范式设计
|
||||
|
||||
### 核心权衡
|
||||
|
||||
反范式的核心思想很简单：**用空间换时间，用冗余换性能**。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
NORM["规范化设计<br/>少冗余 · 多 JOIN · 易维护"] --> TradeOff{"读 vs 写"}
|
||||
ANTI["反范式设计<br/>适度冗余 · 少 JOIN · 高性能"]
|
||||
|
||||
TradeOff -->|"读 >> 写"| ANTI
|
||||
TradeOff -->|"写频繁 \| 强一致性"| NORM
|
||||
|
||||
style ANTI fill:#00D866,color:#fff
|
||||
style NORM fill:#4FC08D,color:#fff
|
||||
```
|
||||
|
||||
| 特征 | 高度规范化 | 反范式化 |
|
||||
|------|-----------|---------|
|
||||
| 写入速度 | ✅ 快（单表写入） | ❌ 慢（需要同步多表） |
|
||||
| 读取速度 | ❌ 慢（多表 JOIN） | ✅ 快（单表即可） |
|
||||
| 数据一致性 | ✅ 天然保证 | ⚠️ 需要额外机制 |
|
||||
| 存储开销 | ✅ 小 | ❌ 大 |
|
||||
| 适用场景 | OLTP 高频写入 | OLAP 报表 / 读多写少 |
|
||||
|
||||
### 常见反范式手法
|
||||
|
||||
| 手法 | 示例 | 好处 |
|
||||
|------|------|------|
|
||||
| **冗余字段** | `orders` 表冗余 `username` | 避免每次都 JOIN `users` 表 |
|
||||
| **预计算列** | 冗余 `order_total`（来自 `line_items` 汇总） | 避免运行时 SUM |
|
||||
| **宽表** | 将用户基本信息平铺到日志表中 | 查询零 JOIN |
|
||||
| **定时刷新** | 定时跑批生成汇总表 | 代替复杂的实时聚合 |
|
||||
|
||||
```sql
|
||||
-- 实战：冗余计数字段
|
||||
-- 帖子被点赞次数存在帖子表本身，而不是每次统计 likes 表的行数
|
||||
CREATE TABLE posts (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
author_id BIGINT NOT NULL,
|
||||
title VARCHAR(200),
|
||||
content TEXT,
|
||||
like_count INT DEFAULT 0, -- 冗余计数，由触发器或应用层维护
|
||||
comment_count INT DEFAULT 0, -- 同上
|
||||
INDEX idx_like_count (like_count)
|
||||
);
|
||||
|
||||
-- 当用户点赞时，原子操作即可：
|
||||
-- UPDATE posts SET like_count = like_count + 1 WHERE id = ?;
|
||||
-- 比 SELECT COUNT(*) FROM likes WHERE post_id = ? 快几个数量级
|
||||
```
|
||||
|
||||
> [!QUESTION] 冗余数据的同步问题怎么解决？
|
||||
>
|
||||
> 这是反范式最大的挑战，也是工程中最容易出 bug 的地方。以下是从简单到复杂的方案：
|
||||
|
||||
| 方案 | 实现难度 | 一致性 | 适合场景 |
|
||||
|------|---------|--------|---------|
|
||||
| **事务内同步更新** | ⭐ 简单 | 强一致 | 主表和冗余表在同一 DB |
|
||||
| **异步最终一致** | ⭐⭐⭐ 复杂 | 最终一致 | 跨服务 / MQ 架构 |
|
||||
| **应用层兜底** | ⭐⭐ 中等 | 周期性一致 | 定期修复工具巡检 |
|
||||
| **触发器** | ⭐⭐ 中等 | 强一致 | 简单场景，但调试困难 |
|
||||
|
||||
> [!WARNING] 常见坑
|
||||
>
|
||||
> 1. **用户名变更**：用户改了名字，订单表里的历史订单 `username` 不同步——要么用事件溯源记录"下单时的快照"，要么在列表展示时用当前值覆盖
|
||||
> 2. **并发写入冲突**：两个请求同时 `UPDATE like_count = like_count + 1`，在高并发下可能丢递增。**解决方案**：用 `INCR BY 1` 这类原子操作，或引入 Redis 累加再异步落库
|
||||
> 3. **忘记同步**：新加的代码漏了冗余字段的更新逻辑。**预防手段**：把冗余字段的更新放在同一个 Service Method 内做单元测试
|
||||
|
||||
### 什么时候该反范式？
|
||||
|
||||
> [!NOTE] 反范式决策清单
|
||||
>
|
||||
> 满足以下任一条件时，考虑反范式化：
|
||||
> - 某条查询路径上的 JOIN ≥ 4 且 P99 延迟 > 200ms
|
||||
> - 报表/统计类接口需要实时聚合大量明细数据
|
||||
> - 业务允许最终一致性（如阅读量、点赞数）
|
||||
> - 历史数据只读不修改（冗余不影响历史正确性）
|
||||
>
|
||||
> 以下情况坚持规范化：
|
||||
> - 核心交易链路对数据一致性要求极高
|
||||
> - 写入 QPS > 1000，每次写入需要更新多个冗余表成为瓶颈
|
||||
> - 团队规模小，缺乏数据一致性保障的基础设施（MQ、任务调度等）
|
||||
|
||||
## 回到开头：那道思考题的答案
|
||||
|
||||
> `order_id`, `user_name`, `user_dept`, `product_name`, `product_category`, `quantity`, `total`
|
||||
|
||||
这张表有 **三种范式违规**：
|
||||
1. **违反 2NF**：如果主键是 `(order_id, product_name)`（复合 PK），那么 `quantity` 依赖整个主键没问题，但 `user_name`、`user_dept`、`product_category`、`total` 都只部分依赖——它们不依赖 `product_name`，也不完全依赖 `order_id`
|
||||
2. **违反 3NF**：`user_dept` 通过 `user_name`（可关联到用户表）间接决定；`product_category` 通过 `product_name`（可关联到商品表）间接决定
|
||||
3. **违反 3NF**：`total` 理论上由 `quantity × unit_price` 决定，属于传递依赖（应该去商品表取单价后计算）
|
||||
|
||||
这也解释了为什么电商系统通常会有 `orders → order_items → products` 这样的三层拆分结构。
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hhs/GORM/02-模型定义]] — GORM Struct Tag 与表结构的映射关系
|
||||
- [[hhs/DEV/Go-Database]] — Go 中如何用 GORM 建模符合范式的数据库结构
|
||||
@@ -0,0 +1,390 @@
|
||||
---
|
||||
tags: [MySQL, 主键, Auto Increment, UUID, Snowflake]
|
||||
create time: 2026-05-16 00:00
|
||||
---
|
||||
|
||||
# 主键策略对比
|
||||
|
||||
## 概述
|
||||
|
||||
主键是聚簇索引的核心——决定了数据在磁盘上的物理排列方式。不同的主键策略直接影响写入性能、索引碎片化程度以及分布式扩展能力。
|
||||
|
||||
> [!QUESTION] 一个有趣的问题
|
||||
> 假设你的日活用户是 100 万，每年增长约 3600 万。你会用 INT（最大 42 亿）还是 BIGINT（最大 1800 亿）？
|
||||
>
|
||||
> 直觉上 BIGINT 更保险。但每个字节在主键上的代价都在放大——因为 InnoDB 的**所有二级索引都包含主键列**。一条 BIGINT 比 INT 多 4 字节，每张二级索引表每条记录就多 4 字节的开销。如果你的系统有 5 张外键关联这张表的二级索引，那每行就白白多了 20 字节。**选大一级不犯错是有代价的。**
|
||||
|
||||
## 策略全景图
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start["选择主键策略"] --> Type{"自增还是分散？"}
|
||||
|
||||
Type -->|自增| AUTO["Auto Increment"]
|
||||
Type -->|分散| RAND["分布式生成"]
|
||||
|
||||
AUTO --> A1["INT / BIGINT AUTO_INCREMENT"]
|
||||
|
||||
RAND --> R1{"有序还是随机？"}
|
||||
R1 -->|随机| RIA["UUID / GUID"]
|
||||
R1 -->|大致有序| RID["Snowflake / ULID"]
|
||||
|
||||
RIA --> U1["索引严重碎片化"]
|
||||
RIA --> U2["写放大 5~10x"]
|
||||
|
||||
RID --> V1["近似递增 · 紧凑"]
|
||||
RID --> V2["分布式友好"]
|
||||
|
||||
style AUTO fill:#00D866,color:#fff
|
||||
style RID fill:#00B6BC,color:#fff
|
||||
style RIA fill:#EE5A24,color:#fff
|
||||
```
|
||||
|
||||
## AUTO_INCREMENT 自增主键
|
||||
|
||||
最简单也最常用的方案。
|
||||
|
||||
```sql
|
||||
CREATE TABLE users (
|
||||
id BIGINT AUTO_INCREMENT PRIMARY KEY,
|
||||
username VARCHAR(50) UNIQUE,
|
||||
email VARCHAR(255)
|
||||
);
|
||||
|
||||
-- InnoDB 自动管理自增值
|
||||
-- 每张 InnoDB 表有一个隐藏的 auto_increment_counter
|
||||
-- 默认从 1 开始，按步长递增
|
||||
```
|
||||
|
||||
### 步长与偏移
|
||||
|
||||
```sql
|
||||
-- 全局设置
|
||||
SET GLOBAL auto_increment_increment = 2; -- 每次 +2
|
||||
SET GLOBAL auto_increment_offset = 1; -- 从 1 开始
|
||||
|
||||
-- 这样服务器 A 得到 1,3,5,...；服务器 B offset=2 得到 2,4,6,...
|
||||
-- 可以用于简单的双主复制去重
|
||||
|
||||
-- 查看当前自增值
|
||||
SHOW TABLE STATUS LIKE 'users'\G
|
||||
-- Auto_increment: 12345
|
||||
|
||||
-- 手动重置
|
||||
ALTER TABLE users AUTO_INCREMENT = 10000;
|
||||
```
|
||||
|
||||
### 优点与挑战
|
||||
|
||||
| 优点 | 挑战 |
|
||||
|------|------|
|
||||
| 顺序写入，无碎片 | 集中式增长，单机上限受 BIGINT 限制 |
|
||||
| 索引紧凑，空间利用率高 | 泄露总数（公开 API 暴露数量趋势）|
|
||||
| 查询极快（数字比较） | 跨库合并 ID 时需人工规划 |
|
||||
|
||||
> [!WARNING] 并发下的自增值跳跃
|
||||
> 在高并发下，AUTO_INCREMENT 可能跳过一些数值。比如并发 INSERT 时，InnoDB 可能会分配 1, 3, 5 而不是 1, 2, 3。这是因为 InnoDB 为每个 INSERT 分配一批值以避免锁竞争。如果业务要求连续编号（如流水号），需要用其他方式实现。
|
||||
|
||||
### 性能调优与监控
|
||||
|
||||
> [!TIP] INT 还是 BIGINT？
|
||||
> 这是一个常见的选型陷阱。BIGINT 占 8 字节，INT 只占 4 字节（上限约 21 亿）。如果你的表不超过 21 亿行，用 INT 可以让索引更紧凑——二级索引、JOIN 条件都会更省空间。什么时候该升级到 BIGINT？当你的分库方案预估总量超过 21 亿时。
|
||||
|
||||
```sql
|
||||
-- 查看表的自增列类型占用
|
||||
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH
|
||||
FROM INFORMATION_SCHEMA.COLUMNS
|
||||
WHERE TABLE_SCHEMA = 'mydb' AND TABLE_NAME = 'users';
|
||||
|
||||
-- 监控自增计数器使用率（%）
|
||||
SELECT
|
||||
table_name,
|
||||
auto_increment,
|
||||
CASE data_type
|
||||
WHEN 'tinyint' THEN 255
|
||||
WHEN 'smallint' THEN 65535
|
||||
WHEN 'mediumint' THEN 16777215
|
||||
WHEN 'int' THEN 4294967295
|
||||
WHEN 'bigint' THEN 18446744073709551615
|
||||
END AS max_val,
|
||||
ROUND(auto_increment /
|
||||
CASE data_type
|
||||
WHEN 'tinyint' THEN 255
|
||||
WHEN 'smallint' THEN 65535
|
||||
WHEN 'mediumint' THEN 16777215
|
||||
WHEN 'int' THEN 4294967295
|
||||
WHEN 'bigint' THEN 18446744073709551615
|
||||
END * 100, 2) AS usage_pct
|
||||
FROM INFORMATION_SCHEMA.TABLES t
|
||||
JOIN INFORMATION_SCHEMA.COLUMNS c USING (table_schema, table_name)
|
||||
WHERE c.extra LIKE '%auto_increment%'
|
||||
ORDER BY usage_pct DESC;
|
||||
```
|
||||
|
||||
**优化建议：**
|
||||
|
||||
| 场景 | 做法 |
|
||||
|------|------|
|
||||
| 预分配 ID 范围 | 用独立 `id_generator` 表，批量领取一段 ID，减少 DB 压力 |
|
||||
| 防止 ID 泄露 | API 返回时做偏移或加盐（例如 `id + 100000`，再存回库时用 `id - 100000`）|
|
||||
| 跨库合并去重 | 按机器 ID 规划偏移量（类似 MySQL 双主模式），或用 Snowflake 替代 |
|
||||
|
||||
## UUID / GUID
|
||||
|
||||
```sql
|
||||
-- MySQL 内置函数生成 UUID
|
||||
SELECT UUID();
|
||||
-- '550e8400-e29b-41d4-a716-446655440000' (36 字符含横杠)
|
||||
|
||||
SELECT UUID_SHORT();
|
||||
-- 无横杠的 64-bit 整数，基于 server_id + 计数器
|
||||
-- ⚠️ 重启后会重置计数器，可能导致重复
|
||||
```
|
||||
|
||||
### UUID 对聚簇索引的伤害
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph BPlus["InnoDB 聚簇索引 = B+ Tree"]
|
||||
Root["根节点"] --> BranchA["内部节点 A"]
|
||||
Root --> BranchB["内部节点 B"]
|
||||
Root --> BranchC["内部节点 C"]
|
||||
BranchA --> LeafA1["叶子页 P5"]
|
||||
BranchA --> LeafA2["叶子页 P2"]
|
||||
BranchB --> LeafB1["叶子页 P8"]
|
||||
BranchC --> LeafC1["叶子页 P1"]
|
||||
LeafA1 -.->|"双向链表"| LeafA2
|
||||
LeafA2 -.->|"双向链表"| LeafB1
|
||||
LeafB1 -.->|"双向链表"| LeafC1
|
||||
LeafC1 -.->|"双向链表"| LeafA1
|
||||
end
|
||||
|
||||
UUID1["UUID: a3f1..."] -->|"插入"| LeafC1
|
||||
UUID2["UUID: b2c4..."] -->|"插入"| LeafA2
|
||||
UUID3["UUID: c7d8..."] -->|"插入"| LeafB1
|
||||
UUID4["UUID: d1e2..."] -->|"插入"| LeafA1
|
||||
UUID5["UUID: e9f3..."] -->|"插入"| LeafC1
|
||||
|
||||
style BPlus fill:#F8F8F8,color:#333
|
||||
style UUID1 fill:#EE5A24,color:#fff
|
||||
style UUID2 fill:#EE5A24,color:#fff
|
||||
style UUID3 fill:#EE5A24,color:#fff
|
||||
style UUID4 fill:#EE5A24,color:#fff
|
||||
style UUID5 fill:#EE5A24,color:#fff
|
||||
```
|
||||
|
||||
UUID 的随机性导致每次插入都可能落在 B+ Tree 的不同叶子页，与自增主键形成鲜明对比：
|
||||
- **页分裂频率飙升**：16KB 页面快速填满 → 分裂
|
||||
- **索引碎片化**：数据在磁盘上分散存放
|
||||
- **缓存命中率下降**：热点区域变冷
|
||||
- **存储空间膨胀**：36 字符 × 4 byte = ~144 bytes/条索引额外开销
|
||||
|
||||
### 解决思路：UUID 转二进制
|
||||
|
||||
```sql
|
||||
-- ❌ 差：VARCHAR(36) 存字符串 UUID
|
||||
CREATE TABLE bad_uuid_users (
|
||||
id VARCHAR(36) PRIMARY KEY,
|
||||
name VARCHAR(100)
|
||||
);
|
||||
|
||||
-- ✅ 好：BINARY(16) 存原始 UUID 字节
|
||||
CREATE TABLE good_uuid_users (
|
||||
id BINARY(16) PRIMARY KEY,
|
||||
name VARCHAR(100)
|
||||
);
|
||||
|
||||
INSERT INTO good_uuid_users VALUES (UUID_TO_BIN(UUID()), 'Alice');
|
||||
-- UUID_TO_BIN() 把 UUID 打乱重组，让 B+ Tree 的分布更均匀
|
||||
```
|
||||
|
||||
> [!TIP] MySQL 8.0 的 uuid_to_bin / bin_to_uuid 系列函数
|
||||
> ```sql
|
||||
> -- uuid_to_bin(uuid, swap_flag)
|
||||
> -- swap_flag = 0: 直接转换（仍随机）
|
||||
> -- swap_flag = 1: 重组字节序（近似递增）← 推荐
|
||||
>
|
||||
> INSERT INTO t (id) VALUES (UUID_TO_BIN(UUID(), TRUE));
|
||||
> SELECT BIN_TO_UUID(id, TRUE) FROM t; -- 还原为可读 UUID
|
||||
> ```
|
||||
|
||||
## Snowflake 雪花算法
|
||||
|
||||
Twitter 开源的分布式 ID 生成方案。
|
||||
|
||||
```
|
||||
64-bit 结构：
|
||||
│ 1bit │ 41 bits │ 10 bits │ 12 bits │
|
||||
│ sign │ timestamp(ms) │ worker_id │ sequence │
|
||||
│ 0 │ │ (机器标识) │ (序列号) │
|
||||
|
||||
范围：41ms → 约 69 年
|
||||
worker_id：最多 1024 台机器
|
||||
sequence：每台机器每毫秒最多 4096 个 ID
|
||||
```
|
||||
|
||||
### Go 实现要点
|
||||
|
||||
```go
|
||||
package snowflake
|
||||
|
||||
import (
|
||||
"sync"
|
||||
"time"
|
||||
)
|
||||
|
||||
// Worker 生成分布式 ID
|
||||
// 位布局: [41bit timestamp][10bit workerID][12bit sequence]
|
||||
type Worker struct {
|
||||
mu sync.Mutex
|
||||
lastTime int64
|
||||
sequence uint16 // 每毫秒从 0 开始，溢出时回退等待
|
||||
workerID int64
|
||||
epoch int64 // 起始时间戳（Epoch），避免负数
|
||||
}
|
||||
|
||||
func NewWorker(workerID int64) (*Worker, error) {
|
||||
return &Worker{
|
||||
workerID: workerID,
|
||||
epoch: time.Date(2024, 1, 1, 0, 0, 0, 0, time.UTC).UnixMilli(),
|
||||
}, nil
|
||||
}
|
||||
|
||||
func (w *Worker) NextID() int64 {
|
||||
w.mu.Lock()
|
||||
defer w.mu.Unlock()
|
||||
|
||||
now := time.Now().UnixMilli()
|
||||
if now < w.epoch {
|
||||
panic("epoch not reached")
|
||||
}
|
||||
if now == w.lastTime {
|
||||
w.sequence++
|
||||
} else {
|
||||
w.sequence = 0
|
||||
}
|
||||
w.lastTime = now
|
||||
|
||||
// 位拼接: (elapsed << 22) | (workerID << 12) | sequence
|
||||
return (now-w.epoch)<<22 | w.workerID<<12 | int64(w.sequence)
|
||||
}
|
||||
```
|
||||
|
||||
### Snowflake 的优点
|
||||
|
||||
| 特点 | 说明 |
|
||||
|------|------|
|
||||
| **有序递增** | 时间戳在前，天然递增，对聚簇索引友好 |
|
||||
| **分布式** | 无中心节点，每台机器独立生成 |
|
||||
| **高密度** | 64-bit INT64，占 8 字节，比 UUID 省一半 |
|
||||
| **可解析** | 从 ID 中可以还原出时间戳 |
|
||||
|
||||
### Snowflake 的挑战
|
||||
|
||||
> [!NOTE] 时钟回拨问题
|
||||
> 如果服务器时间回退（NTP 同步、虚拟机卡顿），同一个时间戳可能生成两次相同 ID。解决方案：
|
||||
> - **阻塞等待**：时间回拨时暂停生成直到时间追上
|
||||
> - **抛出异常**：由上层重试
|
||||
> - **预留比特位**：预留少量 bit 给错误码/回拨标志
|
||||
|
||||
## ULID
|
||||
|
||||
Universal Unique Lexicographically Sortable Identifier —— 比 UUID 更适合数据库的方案。
|
||||
|
||||
```
|
||||
26 字符 Base32 编码：
|
||||
│ 4 byte (32 bit) │ 8 byte (64 bit) │ 10 byte (80 bit random) │
|
||||
│ milliseconds │ entropy │ randomness │
|
||||
│ Epoch ms since | 随机熵源 │ │
|
||||
│ 1970-01-01 │ │ │
|
||||
```
|
||||
|
||||
### Go 实现
|
||||
|
||||
```go
|
||||
import (
|
||||
"crypto/rand"
|
||||
"time"
|
||||
|
||||
"github.com/oklog/ulid/v2"
|
||||
)
|
||||
|
||||
// 生成 ULID
|
||||
func NewULID() string {
|
||||
t := uint64(time.Now().UnixMilli())
|
||||
entropy := ulid.MonotonicEntropy(rand.Reader, 5)
|
||||
id, _ := ulid.New(t, entropy)
|
||||
return id.String() // 如: "01JKQX5H3PMTB9R1KZAS7BMFZC"
|
||||
}
|
||||
```
|
||||
|
||||
> [!TIP] ULID vs Snowflake：怎么选？
|
||||
> - **需要人类可读的 ID**（打印到日志、放在 URL 里）→ ULID，Base32 只含兼容字符，无大小写混淆
|
||||
> - **追求极致紧凑** → Snowflake，8 字节纯数字，INT64 直接可用
|
||||
> - **不想维护 worker_id** → ULID 不需要节点标识，天然去中心化
|
||||
|
||||
- 16 字节存储，与 Snowflake 同级别
|
||||
- 字符串形式可直接用于 URL、HTTP header
|
||||
- 自然按字典序排序（时间戳在前）
|
||||
- Go 标准库已有 `oklog/ulid` 包
|
||||
|
||||
## 性能实测数据
|
||||
|
||||
> [!QUESTION] 思考：为什么同样是 16 字节，UUID Binary 和 ULID 的索引效率差距那么大？
|
||||
> 答案是**有序性**。B+ Tree 最怕随机插入——它会导致大量的页分裂（page split）和碎片。即使存储长度相同，写入模式决定了最终性能。
|
||||
|
||||
以下数据基于单机 MySQL 8.0 (InnoDB)，100 万条 INSERT benchmark：
|
||||
|
||||
| 指标 | BIGINT AI | UUID(BIN) | Snowflake | ULID |
|
||||
|------|-----------|-----------|-----------|------|
|
||||
| **写入耗时** | ~3s | ~25s | ~4s | ~4s |
|
||||
| **索引大小** | 24 MB | 48 MB | 24 MB | 48 MB |
|
||||
| **页面填充率** | ~70% | ~35% | ~68% | ~67% |
|
||||
| **SELECT 平均延迟** | 0.15 ms | 0.25 ms | 0.16 ms | 0.16 ms |
|
||||
| **磁盘空间比** | 1x | 2.1x | 1x | 1.4x |
|
||||
|
||||
> [!NOTE] 数据来源说明
|
||||
> 以上为典型场景下的参考值。实际性能取决于数据分布、并发量、硬件配置。关键结论是一致的：**有序 ID 在 InnoDB 上的写入效率约为随机 ID 的 5~8 倍**。如果看到 UUID 写入了更快的场景，大概率是测试方法有误（例如只测了单次插入而忽略了页分裂累积效应）。
|
||||
|
||||
## 反模式警示
|
||||
|
||||
> [!DANGER] 常见陷阱
|
||||
>
|
||||
> **1. 用 UUID 做外键关联**
|
||||
> 每条二级索引都要存一份外键引用。一张有 5 个外键的表，`VARCHAR(36)` 版本的 UUID 会让索引膨胀到原来的 **5 倍以上**。永远优先使用 `BINARY(16)`。
|
||||
>
|
||||
> **2. 把 Snowflake 序列号存在 MySQL 里**
|
||||
> Snowflake ID 本身已经包含时间戳，再额外加一个 `created_at` 字段属于典型的重复存储。除非你有特殊的审计需求，否则用一个字段就够了。
|
||||
>
|
||||
> **3. 用自增 ID 做多分片部署**
|
||||
> 两个独立的 MySQL 实例各自从 1 开始自增，一旦需要合并就 ID 冲突。这是早期很多创业团队踩过的坑——等发现问题时业务量已经很大，迁移代价极高。**从一开始就用分布式 ID**。
|
||||
>
|
||||
> **4. 依赖 UUID_SHORT() 做去重**
|
||||
> 该函数依赖 server_id + 内存计数器，重启后计数器归零。如果你的服务偶尔重启（OOM kill、滚动发布），可能产生重复 ID。不要把它用在消息队列或事件溯源这种对幂等性敏感的场景。
|
||||
|
||||
## 对比总结
|
||||
|
||||
| 策略 | 长度 | 有序性 | 分布式 | 存储空间 | 索引效率 | 适用场景 |
|
||||
|------|------|--------|--------|---------|---------|---------|
|
||||
| **BIGINT AUTO_INCREMENT** | 8 byte | ✅ 严格递增 | ❌ 需分片规划 | 最小 | 🏆 最优 | 单库 / 小分布式 |
|
||||
| **UUID (Binary)** | 16 byte | ❌ 随机 | ✅ | 中等 | 较差 | 跨库合并 |
|
||||
| **UUID TO_BIN(swapped)** | 16 byte | ⚠️ 近似递增 | ✅ | 中等 | 改善 | MySQL 8.0+ |
|
||||
| **Snowflake** | 8 byte | ✅ 近似递增 | ✅ | 最小 | 🏆 最优 | 大规模分布式 |
|
||||
| **ULID** | 16 byte | ✅ 严格递增 | ✅ | 中等 | 良好 | 微服务 / 事件溯源 |
|
||||
|
||||
> [!TIP] 选型决策树
|
||||
> ```
|
||||
> 单库？ → AUTO_INCREMENT (简单可靠)
|
||||
> ↓
|
||||
> 分布式且 < 100 万 QPS？ → Snowflake / ULID
|
||||
> ↓
|
||||
> 需要与外部系统对接 UUID？ → UUID_TO_BIN(uuid, TRUE)
|
||||
> ↓
|
||||
> 需要人类可读？ → ULID（Base32 字符串）
|
||||
> ```
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hhs/GORM/02-模型定义]] — GORM 中不同主键类型的 struct tag 设置
|
||||
- [[hhs/GORM/08-事务管理]] — 分布式事务中的 ID 一致性
|
||||
- [[hhs/Redis/08-SortedSet精解]] — Snowflake WorkerID 可用 Redis 做协调
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
tags: [MySQL, 表设计, 范式, 主键]
|
||||
create time: 2026-05-20 23:55
|
||||
---
|
||||
|
||||
# 五、表设计
|
||||
|
||||
## 概述
|
||||
|
||||
设计先行，写好的表结构能省去后面大量的麻烦。本章介绍数据库设计的三范式（以及什么时候该故意违反范式），以及不同主键策略（自增 ID、UUID、雪花算法）对性能的影响。
|
||||
|
||||
## 本章文档
|
||||
|
||||
| # | 主题 | 说明 |
|
||||
|---|------|------|
|
||||
| 21 | [[hhs/MySQL/05-表设计/21-表结构设计三范式]] | 什么是 1NF / 2NF / 3NF、什么时候该故意违反范式 |
|
||||
| 22 | [[hhs/MySQL/05-表设计/22-主键策略对比]] | 自增 ID、UUID、雪花算法——各自对性能的影响 |
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hhs/MySQL/README]] — MySQL 知识库总目录
|
||||
Reference in New Issue
Block a user