478 lines
20 KiB
Markdown
478 lines
20 KiB
Markdown
|
---
|
|||
|
|
tags: [MySQL, DDL, ALTER TABLE, CREATE TABLE, DATATYPE, NULL, ONLINE DDL, INDEX, CHARACTER SET, SNOWFLAKE, PRIMARY KEY]
|
|||
|
|
create time: 2026-05-16 00:00
|
|||
|
|
update time: 2026-05-20 12:00
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# DDL — 建表与结构变更
|
|||
|
|
|
|||
|
|
## 概述
|
|||
|
|
|
|||
|
|
DDL（Data Definition Language）用于定义和修改数据库对象的结构。本章从最基础的 `CREATE TABLE` 语法出发，覆盖数据类型选型、主键策略、索引设计原则与常见反模式，然后深入 `ALTER TABLE` 操作与在线 DDL 机制，最后给出生产环境的完整 DDL 检查清单。
|
|||
|
|
|
|||
|
|
## CREATE TABLE
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
CREATE TABLE users (
|
|||
|
|
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
|
|||
|
|
username VARCHAR(50) NOT NULL COMMENT '用户名',
|
|||
|
|
email VARCHAR(255) NOT NULL COMMENT '邮箱唯一',
|
|||
|
|
password_hash VARCHAR(64) NOT NULL COMMENT 'bcrypt hash',
|
|||
|
|
status TINYINT NOT NULL DEFAULT 1 COMMENT '1=active 0=disabled',
|
|||
|
|
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
|||
|
|
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
|
|||
|
|
|
|||
|
|
UNIQUE KEY uk_email (email),
|
|||
|
|
INDEX idx_username (username),
|
|||
|
|
INDEX idx_status_created (status, created_at)
|
|||
|
|
) ENGINE=InnoDB
|
|||
|
|
DEFAULT CHARSET=utf8mb4
|
|||
|
|
COLLATE=utf8mb4_0900_ai_ci
|
|||
|
|
COMMENT='用户表';
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 关键语法解析
|
|||
|
|
|
|||
|
|
| 子句 | 作用 |
|
|||
|
|
|------|------|
|
|||
|
|
| `ENGINE=InnoDB` | 显式指定存储引擎（8.0 默认值）|
|
|||
|
|
| `DEFAULT CHARSET` | 数据库级字符集覆盖 |
|
|||
|
|
| `ON UPDATE CURRENT_TIMESTAMP` | 自动维护更新时间戳 |
|
|||
|
|
| `UNIQUE KEY` | 唯一索引，同时约束数据唯一性 |
|
|||
|
|
| `INDEX idx_name (col)` | 普通索引，辅助查询 |
|
|||
|
|
| `COMMENT` | 表和字段注释，可通过 `SHOW FULL COLUMNS` 查看 |
|
|||
|
|
|
|||
|
|
> [!TIP] 命名规范约定
|
|||
|
|
> - **索引名**：`idx_表名_列名`（普通索引）、`uk_表名_列名`（唯一索引）——避免超过 64 字符
|
|||
|
|
> - **时间字段**：统一用 `DATETIME` 而非 `TIMESTAMP`。后者范围仅限 `1970~2038`，遇到闰秒时会报错
|
|||
|
|
> - **自增主键**：务必用 `UNSIGNED`，正数区间翻倍（0 ~ 42.9 亿），且能略微节省空间
|
|||
|
|
|
|||
|
|
> [!QUESTION] 思考：为什么 `password_hash` 要用 `VARCHAR(64)` 而不是固定长度？
|
|||
|
|
> 答案取决于你使用的哈希算法。bcrypt 输出为 60 字符（如 `$2b$12$...`），预留 64 留有扩展余量。如果改用 SHA-256 则恰好 64 字节，此时 `CHAR(64)` 反而更高效——因为固定长度无需额外存储长度前缀。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 数据类型选择指南
|
|||
|
|
|
|||
|
|
建表时数据类型直接决定磁盘占用和查询性能。以下是常见场景的经验推荐：
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph TD
|
|||
|
|
A["需要整数?"] -->|"是"| B["选择尺寸"]
|
|||
|
|
B --> C["TINYINT<br/>-128 ~ 127"]
|
|||
|
|
B --> D["SMALLINT<br/>-3.2 万 ~ 3.2 万"]
|
|||
|
|
B --> E["MEDIUMINT<br/>-838 万 ~ 838 万"]
|
|||
|
|
B --> F["INT<br/>-21 亿 ~ 21 亿"]
|
|||
|
|
B --> G["BIGINT<br/>±922 亿亿"]
|
|||
|
|
|
|||
|
|
A -->|"否"| H["字符串?"]
|
|||
|
|
H --> I["变长 < 255"]
|
|||
|
|
I --> J["VARCHAR(N)"]
|
|||
|
|
H --> K["定长 (密码/签名/IP)"]
|
|||
|
|
K --> L["CHAR(N)"]
|
|||
|
|
H --> M["超长 (文章/JSON)"]
|
|||
|
|
M --> N["TEXT / LONGTEXT"]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
| 类型家族 | 适用场景 | 避坑提示 |
|
|||
|
|
|----------|---------|---------|
|
|||
|
|
| `TINYINT` | 状态标记、布尔值 | 建议加 `UNSIGNED`，0~255 足够 |
|
|||
|
|
| `INT` | 计数器、外键引用 | 数字型 ID 优先 `INT UNSIGNED`，超 42 亿再用 `BIGINT` |
|
|||
|
|
| `VARCHAR(N)` | 用户名、邮箱、地址 | N 按实际 +20% 余量；不要盲目设 255 |
|
|||
|
|
| `DATETIME` | 所有时间戳 | MySQL 8.0 推荐；避免 `TIMESTAMP` 的 2038 年瓶颈 |
|
|||
|
|
| `DECIMAL(M,D)` | 金额 | **绝对禁止**用 `FLOAT/DOUBLE` 存储财务数据 |
|
|||
|
|
|
|||
|
|
#### 一个常见的反例
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- ❌ 错误：用 FLOAT 存价格，会出现精度丢失
|
|||
|
|
price FLOAT DEFAULT 0.00,
|
|||
|
|
|
|||
|
|
-- ✅ 正确：DECIMAL 精确表示货币，M 总位数 D 小数位
|
|||
|
|
price DECIMAL(10, 2) DEFAULT 0.00 COMMENT '单位：元',
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!NOTE] DECIMAL(10,2) 表示最多 10 位数字，其中 2 位在小数点后，即最大值为 `99999999.99`。在 InnoDB 内部以二进制紧凑存储，性能接近整数类型。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 主键设计选型
|
|||
|
|
|
|||
|
|
InnoDB 是 **索引组织表（IOT）**——数据和聚簇索引存于一体。主键的选择直接影响磁盘布局、二级索引大小和分库分表的可行性。
|
|||
|
|
|
|||
|
|
| 方案 | 长度 | 有序性 | 可预测性 | 适用场景 |
|
|||
|
|
|------|------|--------|---------|---------|
|
|||
|
|
| `BIGINT AUTO_INCREMENT` | 8 字节 | ✅ 天然有序 | ❌ 单调递增暴露业务量 | 单库单表、中小型项目 |
|
|||
|
|
| `BIGINT UNSIGNED` + 外部生成器 | 8 字节 | ❌ 随机 | ✅ 不可预测 | 高并发分布式场景 |
|
|||
|
|
| `CHAR(36) UUID()` | 36 字节 | ❌ 完全随机 | ✅ 不可预测 | 需要全局唯一 ID 的场景 |
|
|||
|
|
| `CHAR(26) ULID / Base62 Snowflake` | 26 字节 | ✅ 时间有序 | ✅ 不可预测 | **推荐**：分布式 + 有序 + 紧凑 |
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- ❌ 不推荐：直接用 UUID() 作主键（8.0.13 之前）
|
|||
|
|
id CHAR(36) PRIMARY KEY DEFAULT (UUID())
|
|||
|
|
-- 问题：① 36 字节膨胀二级索引；② 随机写入导致页分裂严重；
|
|||
|
|
-- ③ B+ 树高度增加，缓冲池命中率下降
|
|||
|
|
|
|||
|
|
-- ✅ 推荐：Snowflake 风格 64 位整数
|
|||
|
|
-- 1 bit 符号位 + 41 bit 毫秒时间戳 + 10 bit 机器标识 + 12 bit 序列号
|
|||
|
|
-- 最大 ID = 2^63 - 1 ≈ 922 亿亿，可支撑到公元 2262 年
|
|||
|
|
id BIGINT UNSIGNED NOT NULL PRIMARY KEY
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!QUESTION] 为什么 Snowflake 比 UUID 更受青睐？
|
|||
|
|
> 核心在于 **B+ 树的插入局部性**。Snowflake ID 大致有序，InnoDB 可以追加写入最后一页，开销极小。而 UUID v4 完全随机，每次插入都可能触发页面分裂和页迁移，在高并发写入时性能差距可达 **5~10 倍**。
|
|||
|
|
|
|||
|
|
> [!TIP] 自增主键的安全隐患
|
|||
|
|
> 连续递增的 ID 会泄露业务量级信息（竞争对手可通过 API 返回的 ID 推测日活）。若需隐藏业务数据，可在应用层用 AES 加密 ID（[Pseudo Random ID](https://github.com/yookoala/pagination-adapter#prandomid)），或在数据库层添加 `INSERT` 前 `RAND()` 扰序。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 索引设计与反模式
|
|||
|
|
|
|||
|
|
索引是 DDL 中最值得投入精力、也最容易被滥用的部分。一个好的索引可以让查询从全表扫描降到 O(log N)。
|
|||
|
|
|
|||
|
|
### 基本原则
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- ✅ 最左前缀原则：联合索引 (a, b, c)
|
|||
|
|
INDEX idx_abc (a, b, c)
|
|||
|
|
|
|||
|
|
-- 以下查询都能命中索引
|
|||
|
|
WHERE a = 1 -- ✓ (a,)
|
|||
|
|
WHERE a = 1 AND b = 2 -- ✓ (a,b)
|
|||
|
|
WHERE a = 1 AND b = 2 AND c = 3 -- ✓ (a,b,c)
|
|||
|
|
WHERE a = 1 AND c = 3 -- ✓ (a,) + filescan 查 c
|
|||
|
|
|
|||
|
|
-- 以下查询只能命中部分索引
|
|||
|
|
WHERE b = 2 AND c = 3 -- ✗ 只用了 (a,b,c) 中的 c，b 无法利用
|
|||
|
|
WHERE a > 1 AND b = 2 -- ✓ 只有 b 能用到索引，c 不能（> 后断链）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!TIP] 最左前缀匹配口诀
|
|||
|
|
> **「从左往右，碰到范围就停」**——一旦遇到 `>`、`<`、`BETWEEN`、`LIKE 'abc%'` 这类范围条件，后面的列就不再参与索引查找。这也是为什么把等值列放在联合索引前面的原因。
|
|||
|
|
|
|||
|
|
### 覆盖索引 & 回表
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- 假设表有 PRIMARY KEY (id), INDEX idx_status (status)
|
|||
|
|
|
|||
|
|
-- ❌ 需要回表：查出不在索引中的列
|
|||
|
|
SELECT id, username, email FROM users WHERE status = 1;
|
|||
|
|
-- → 先查 idx_status 找到 id，再按 id 回聚簇索引拿 username/email
|
|||
|
|
|
|||
|
|
-- ✅ 覆盖索引：所有所需列都在索引中，无需回表
|
|||
|
|
SELECT id FROM users WHERE status = 1;
|
|||
|
|
-- → 直接从 idx_status 取 id，零回表
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!NOTE] 覆盖索引（Covering Index）是性能优化的杀手锏。当查询只需的列全部包含在某个二级索引中时，InnoDB 可以直接从索引树提取数据，无需再访问聚簇索引，大幅减少 I/O。
|
|||
|
|
|
|||
|
|
### 常见反模式
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- ❌ 函数包裹导致索引失效
|
|||
|
|
SELECT * FROM users WHERE YEAR(created_at) = 2025;
|
|||
|
|
-- ✅ 改写为范围查询，利用索引
|
|||
|
|
SELECT * FROM users
|
|||
|
|
WHERE created_at >= '2025-01-01' AND created_at < '2026-01-01';
|
|||
|
|
|
|||
|
|
-- ❌ 隐式类型转换
|
|||
|
|
CREATE TABLE products (sku VARCHAR(20) NOT NULL);
|
|||
|
|
SELECT * FROM products WHERE sku = 12345; -- 字符串被转成数字
|
|||
|
|
-- ✅ 保持类型一致
|
|||
|
|
SELECT * FROM products WHERE sku = '12345';
|
|||
|
|
|
|||
|
|
-- ❌ LIKE 通配符在前
|
|||
|
|
SELECT * FROM users WHERE username LIKE '%admin%';
|
|||
|
|
-- ✅ 改写为全文搜索或调整匹配策略
|
|||
|
|
SELECT * FROM users WHERE username LIKE 'admin%'; -- 可以用索引
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!WARNING] 隐式类型转换是最隐蔽的性能杀手
|
|||
|
|
> 当列定义为 `VARCHAR` 但传入的是数值（反之亦然），MySQL 会在每一行上做隐式转换，**导致索引直接失效**。执行 `EXPLAIN` 看到 `type=ALL` 且无 `Using where` 优化时，第一反应就是检查类型是否匹配。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 字符集与排序规则
|
|||
|
|
|
|||
|
|
字符集决定了数据如何编码存储，排序规则决定了字符串比较的顺序。选错会导致乱码、排序错误甚至查询走不了索引。
|
|||
|
|
|
|||
|
|
| 排序规则 | 特点 | 适用场景 |
|
|||
|
|
|----------|------|---------|
|
|||
|
|
| `utf8mb4_general_ci` | 速度快但不精确，已废弃 | 旧系统兼容 |
|
|||
|
|
| `utf8mb4_bin` | 精确的二进制比较，区分大小写 | 密码、Token 等敏感字段 |
|
|||
|
|
| `utf8mb4_0900_ai_ci` | 8.0 默认，Unicode 9.0 准确排序 | **通用推荐** |
|
|||
|
|
| `utf8mb4_zh_pinyin_ci` | 按拼音排序中文 | 中文名排序场景 |
|
|||
|
|
|
|||
|
|
> [!TIP] utf8 不是真正的 UTF-8！
|
|||
|
|
> MySQL 中的 `utf8` 只是一个缩写，最大只支持 3 字节的字符（缺少 Emoji 等 4 字节 Unicode）。**始终使用 `utf8mb4`**，哪怕你确定没有 Emoji。
|
|||
|
|
|
|||
|
|
> [!QUESTION] 排序规则影响索引吗？
|
|||
|
|
> 是的。如果表 A 用 `utf8mb4_0900_ai_ci` 而表 B 用 `utf8mb4_bin`，两个表做 JOIN 时 MySQL 会在运行时做临时转换，可能导致无法使用索引。关联表的字符集和排序规则应保持一致。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## MySQL 8.0 新增能力
|
|||
|
|
|
|||
|
|
### 不可见索引（Invisible Indexes）
|
|||
|
|
|
|||
|
|
上线前验证索引有效性的利器，无需真正删除索引即可测试其影响：
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- 将索引设为不可见（优化器不再使用它）
|
|||
|
|
ALTER TABLE orders ALTER INDEX idx_status INVISIBLE;
|
|||
|
|
|
|||
|
|
-- 验证性能影响后，确认无用再删除
|
|||
|
|
DROP INDEX idx_status ON orders;
|
|||
|
|
|
|||
|
|
-- 恢复可见
|
|||
|
|
ALTER TABLE orders ALTER INDEX idx_status VISIBLE;
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!TIP] 渐进式下线索引流程
|
|||
|
|
> 1. 设置 `INVISIBLE` → 观察慢查询和错误率 1~7 天
|
|||
|
|
> 2. 确认无负面影响 → `DROP INDEX`
|
|||
|
|
> 3. 此方法比直接 `DROP` 更安全，相当于一次「灰度发布」
|
|||
|
|
|
|||
|
|
### 表达式索引（Functional Indexes）
|
|||
|
|
|
|||
|
|
8.0.13+ 支持对函数结果建立索引，无需冗余列：
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- 对 JSON 字段内的嵌套属性建立索引
|
|||
|
|
ALTER TABLE events ADD INDEX json_idx ((JSON_UNQUOTE(JSON_EXTRACT(data, '$.type'))));
|
|||
|
|
|
|||
|
|
-- 对大小写不敏感的搜索建索引
|
|||
|
|
ALTER TABLE users ADD INDEX lower_email_idx ((LOWER(email)));
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 窗口函数与 CTE
|
|||
|
|
|
|||
|
|
DDL 本身不涉及这些，但它们改变了我们设计表结构的方式——有了分析函数后，某些聚合维度表可以简化：
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- 传统做法：额外建一张月粒度汇总表
|
|||
|
|
CREATE TABLE sales_monthly (
|
|||
|
|
month DATE NOT NULL,
|
|||
|
|
total DECIMAL(12,2),
|
|||
|
|
PRIMARY KEY (month)
|
|||
|
|
);
|
|||
|
|
|
|||
|
|
-- 8.0 有了窗口函数后，很多场景可以直接在原表上计算
|
|||
|
|
SELECT sales_date, amount,
|
|||
|
|
SUM(amount) OVER (ORDER BY sales_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg_7d
|
|||
|
|
FROM daily_sales;
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## ALTER TABLE — 常见操作
|
|||
|
|
|
|||
|
|
### 增删改列
|
|||
|
|
|
|||
|
|
`CHANGE` 与 `MODIFY` 的区别在于：**CHANGE 必须同时写出列名（可改名）**，而 MODIFY 只改属性不更名。这是初学最容易混淆的地方。
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- 添加列
|
|||
|
|
ALTER TABLE users ADD COLUMN phone VARCHAR(20) AFTER email;
|
|||
|
|
ALTER TABLE users ADD COLUMN last_login_ip VARCHAR(45); -- IPv4/IPv6 通用
|
|||
|
|
|
|||
|
|
-- 修改列类型（不改名）
|
|||
|
|
ALTER TABLE users MODIFY COLUMN status TINYINT UNSIGNED DEFAULT 0;
|
|||
|
|
|
|||
|
|
-- 重命名列（改名 + 可选改类型）
|
|||
|
|
ALTER TABLE users CHANGE COLUMN phone phone_number VARCHAR(20);
|
|||
|
|
|
|||
|
|
-- 删除列
|
|||
|
|
ALTER TABLE users DROP COLUMN last_login_ip;
|
|||
|
|
|
|||
|
|
-- 删除索引
|
|||
|
|
ALTER TABLE users DROP INDEX idx_username;
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!WARNING] ALTER TABLE DROP COLUMN 不可逆
|
|||
|
|
> 列一旦删除，其中的数据和统计信息全部消失。**生产环境执行 DDL 前务必确认已有备份**。现代运维流程中应通过迁移工具（见关联笔记）做版本化管理，而非手动执行 ALTER。
|
|||
|
|
|
|||
|
|
### 在线 DDL（ALGORITHM / LOCK）
|
|||
|
|
|
|||
|
|
MySQL 5.6+ 支持 Online DDL，允许在结构变更期间持续处理读写请求。
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- 三种算法对比
|
|||
|
|
ALTER TABLE users ADD COLUMN bio TEXT, ALGORITHM=INPLACE;
|
|||
|
|
ALTER TABLE users ADD COLUMN bio TEXT, ALGORITHM=COPY;
|
|||
|
|
ALTER TABLE users ADD COLUMN bio TEXT; -- 8.0 默认 INPLACE
|
|||
|
|
|
|||
|
|
-- 三种锁策略对比
|
|||
|
|
ALTER TABLE ... LOCK=NONE; -- 不阻塞任何读/写（最安全）
|
|||
|
|
ALTER TABLE ... LOCK=SHARED; -- 允许并发读，阻塞写
|
|||
|
|
ALTER TABLE ... LOCK=EXCLUSIVE; -- 阻塞所有其他操作（最快）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!NOTE] INPLACE vs COPY 的本质区别
|
|||
|
|
> - **INPLACE**：直接在原表上重建索引或新增索引，不需要全表拷贝数据。支持的场景包括：增加/删除索引、改变列默认值、新增列等。
|
|||
|
|
> - **COPY**：创建临时表 → 逐行拷贝数据 → 原子替换。适用于改变列定义导致格式不兼容的场景，比如 `VARCHAR` 改 `INT`。
|
|||
|
|
>
|
|||
|
|
> **经验法则**：8.0 默认的 `INPLACE` 对大多数操作都够用。若不确定，先跑 `pt-online-schema-change --dry-run` 看预估耗时。
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart LR
|
|||
|
|
Start["ALTER TABLE 开始"] --> Alg{"ALGORITHM"}
|
|||
|
|
|
|||
|
|
Alg -->|INPLACE| Inplace["原地重建索引"]
|
|||
|
|
Alg -->|COPY| Copy["创建临时表拷贝数据"]
|
|||
|
|
Alg -->|DEFAULT(8.0)| Inplace
|
|||
|
|
|
|||
|
|
Inplace --> Lock{"LOCK"}
|
|||
|
|
Copy --> Lock
|
|||
|
|
|
|||
|
|
Lock|NONE| Online["在线<br/>读写不阻塞"]
|
|||
|
|
Lock|SHARED| ReadConc["并发读<br/>写入等待"]
|
|||
|
|
Lock|EXCLUSIVE| BlockAll["排他锁<br/>速度最快"]
|
|||
|
|
|
|||
|
|
style Online fill:#00D866,color:#fff
|
|||
|
|
style ReadConc fill:#FF9F43,color:#000
|
|||
|
|
style BlockAll fill:#EE5A24,color:#fff
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 大表 DDL 实战技巧
|
|||
|
|
|
|||
|
|
对百万行以上的表执行 `ALTER TABLE` 时：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
# ❌ 危险：直接在线上执行
|
|||
|
|
ALTER TABLE big_table ADD INDEX idx_col (col);
|
|||
|
|
|
|||
|
|
# ✅ 方案一：pt-online-schema-change（Percona Toolkit）
|
|||
|
|
pt-online-schema-change \
|
|||
|
|
--user=root --password=xxx \
|
|||
|
|
--alter "ADD INDEX idx_col (col)" \
|
|||
|
|
D=mydb,t=big_table \
|
|||
|
|
--execute
|
|||
|
|
|
|||
|
|
# ✅ 方案二：gh-ost（GitHub 开源）
|
|||
|
|
gh-ost \
|
|||
|
|
--user=root --password=xxx \
|
|||
|
|
--host=127.0.0.1 --port=3306 \
|
|||
|
|
--database=mydb \
|
|||
|
|
--table=big_table \
|
|||
|
|
--alter "ADD INDEX idx_col (col)" \
|
|||
|
|
--allow-on-master \
|
|||
|
|
--execute
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!TIP] pt-osc 原理三步走
|
|||
|
|
> 1. **创建新表**：与原表结构一致 + 目标变更
|
|||
|
|
> 2. **触发器同步**：创建 INSERT/UPDATE/DELETE 触发器，将原表的变更实时同步到新表
|
|||
|
|
> 3. **原子替换**：加排他锁极短时间，swap 两张表名后删除触发器和旧表
|
|||
|
|
|
|||
|
|
> [!QUESTION] gh-ost 和 pt-osc 怎么选？
|
|||
|
|
> - **pt-osc** 依赖触发器，对高并发写密集型表有较大开销
|
|||
|
|
> - **gh-ost** 基于 binlog 解析，无需触发器，对线上影响更小
|
|||
|
|
> - **结论**：新项目优先 gh-ost；老项目已有 pt-toolkit 积累也可以用 pt-osc
|
|||
|
|
|
|||
|
|
### 生产环境 DDL Checklist
|
|||
|
|
|
|||
|
|
在执行任何 `ALTER TABLE` 之前，逐项核对这份清单。养成习惯可以避免 90% 的线上事故。
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
□ 1. 确认操作有对应的应用代码上线计划
|
|||
|
|
└─ DDL 与应用逻辑必须同步上线，否则可能出现字段不存在但代码已读写该字段的竞态
|
|||
|
|
|
|||
|
|
□ 2. 预估耗时（先在预发/从库验证）
|
|||
|
|
└─ SELECT COUNT(*) FROM big_table; → 根据行数估算 COPY 耗时
|
|||
|
|
└─ 或使用 --dry-run 模式（pt-osc / gh-ost 均支持）
|
|||
|
|
|
|||
|
|
□ 3. 选择 ALGORITHM=INPLACE + LOCK=NONE
|
|||
|
|
└─ 只有在无法在线完成时才考虑 LOCK=EXCLUSIVE + 低峰期执行
|
|||
|
|
|
|||
|
|
□ 4. 检查磁盘空间 ≥ 当前表大小 × 2
|
|||
|
|
└─ INPLACE 通常只需少量额外空间；COPY 需要整份表的临时空间
|
|||
|
|
|
|||
|
|
□ 5. 确认主从复制延迟可控
|
|||
|
|
└─ DDL 在主库完成前从库会一直阻塞，DDL 完成后可能瞬间追赶大量事件
|
|||
|
|
└─ 建议在监控中关注 Seconds_Behind_Master
|
|||
|
|
|
|||
|
|
□ 6. 评估二级索引数量上限
|
|||
|
|
└─ 每张表建议不超过 5~7 个索引（含主键）
|
|||
|
|
└─ 每个索引都会拖慢 INSERT/UPDATE/DELETE
|
|||
|
|
└─ 使用不可见索引先下线无用索引，再删除
|
|||
|
|
|
|||
|
|
□ 7. 准备回滚方案
|
|||
|
|
└─ 记录 ALTER 前的 CREATE TABLE 语句（SHOW CREATE TABLE）
|
|||
|
|
└─ 如果新结构有问题，可以用原语句重建表
|
|||
|
|
|
|||
|
|
□ 8. 更新文档和迁移脚本
|
|||
|
|
└─ 关联笔记中的 GORM model、migration 文件需要同步修改
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!WARNING] 最危险的操作顺序
|
|||
|
|
> 1. **先发代码改逻辑读旧列名** → 此时新列还不存在，查询报 `Unknown column`
|
|||
|
|
> 2. **再执行 ALTER TABLE ADD COLUMN** → 解决第一步的问题，但已有脏数据
|
|||
|
|
> 3. **最后清理旧列** → 第三次发布才能安全 DROP
|
|||
|
|
>
|
|||
|
|
> **最佳做法**：先用 `ADD COLUMN` + 双写（新旧并存），然后发代码切换到新字段，最后再 `DROP OLD_COLUMN`——三步走，每次只做一个动作。
|
|||
|
|
|
|||
|
|
### NULL vs NOT NULL — 选型指南
|
|||
|
|
|
|||
|
|
这是 DDL 中最常见的争论之一。核心原则：**能用 NOT NULL 就不用 NULL**。
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph TD
|
|||
|
|
Q1["是否允许未知状态?"] -->|否| NN["NOT NULL + DEFAULT"]
|
|||
|
|
Q1 -->|是| Biz{"业务语义?"}
|
|||
|
|
|
|||
|
|
Biz -->|逻辑删除/软删| SoftDel["TINYINT DEFAULT 0<br/>0=正常 1=已删除"]
|
|||
|
|
Biz -->| truly optional | AllowNull["允许 NULL<br/>但加注释说明含义"]
|
|||
|
|
|
|||
|
|
style NN fill:#00D866,color:#fff
|
|||
|
|
style SoftDel fill:#FF9F43,color:#000
|
|||
|
|
style AllowNull fill:#EE5A24,color:#fff
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
| 维度 | NOT NULL + DEFAULT | 允许 NULL |
|
|||
|
|
|------|-------------------|----------|
|
|||
|
|
| **索引效率** | InnoDB 二级索引不存储纯 NULL 值，用默认值占位可减少索引碎片 | 包含 NULL 标记的索引需要额外 1 bit |
|
|||
|
|
| **查询安全** | `WHERE col = ?` 不会遗漏任何行 | `WHERE col = 'value'` **排除了 NULL 行**（需用 `IS NULL`） |
|
|||
|
|
| **聚合函数** | SUM/COUNT 直接可用 | COUNT(col) 忽略 NULL 行，容易误判总行数 |
|
|||
|
|
| **可读性** | `status = 0` 一目了然 | `status IS NULL` 语义模糊——到底是"还没填"还是"被清除了"? |
|
|||
|
|
|
|||
|
|
> [!WARNING] NULL 的三个常见误区
|
|||
|
|
> 1. **"NULL 占空间更小"**：InnoDB 中 NULL 也需要在行格式中标记，固定为每 8 个字节 1 bit 的 null bitmap。比存一个空字符串或零值并不节省什么。
|
|||
|
|
> 2. **"NULL = NULL"**：在 SQL 三值逻辑中，`NULL = NULL` 结果为 UNKNOWN，永远不等于 TRUE。判断必须用 `IS NULL` / `IS NOT NULL`。
|
|||
|
|
> 3. **"外键可以为 NULL"**：技术上可以，但会导致孤儿记录难以追踪。建议用显式的 `deleted_at` 时间戳代替外键 NULL 做软删除。
|
|||
|
|
|
|||
|
|
## 常用 DDL 查询
|
|||
|
|
|
|||
|
|
这些 SQL 命令帮助你查看当前数据库的「结构全貌」，在排查索引失效、表空间膨胀时尤其有用。
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
-- 查看表完整创建语句（含所有索引、注释、引擎配置）
|
|||
|
|
SHOW CREATE TABLE users\G
|
|||
|
|
|
|||
|
|
-- 查看所有索引（含索引类型、列顺序、唯一性）
|
|||
|
|
SHOW INDEX FROM users\G
|
|||
|
|
|
|||
|
|
-- 查看表统计信息（Rows 为估算值，非精确计数）
|
|||
|
|
SHOW TABLE STATUS LIKE 'users'\G
|
|||
|
|
-- 重点关注 Rows（估算行数）、Data_length、Index_length
|
|||
|
|
|
|||
|
|
-- 查看分区情况
|
|||
|
|
SELECT PARTITION_NAME, PARTITION_EXPRESSION, PARTITION_DESCRIPTION
|
|||
|
|
FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'logs';
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!TIP] 快速定位慢查询相关的结构问题
|
|||
|
|
> ```sql
|
|||
|
|
> -- 检查表是否存在大量碎片的索引（数据删除后未回收的空间）
|
|||
|
|
> SELECT TABLE_NAME, INDEX_NAME, CARDINALITY
|
|||
|
|
> FROM INFORMATION_SCHEMA.STATISTICS
|
|||
|
|
> WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'users'
|
|||
|
|
> ORDER BY CARDINALITY ASC;
|
|||
|
|
>
|
|||
|
|
> -- 低基数（CARDINALITY 接近 0）的索引通常效果不佳，考虑移除
|
|||
|
|
> ```
|
|||
|
|
|
|||
|
|
## 关联笔记
|
|||
|
|
|
|||
|
|
- [[hhs/GORM/02-模型定义]] — GORM AutoMigrate 等价于 DDL 的自动化版本
|
|||
|
|
- [[hhs/GORM/17-迁移工具]] — Schema 迁移管理最佳实践
|