御道御小黑先交代下背景。这是“生成测试数据”这个系列的第三篇。前两篇一篇在聊“造数据前先想清楚测试目标”，一篇在讲“数据脱敏和脱敏后的可用性”，这篇直接落到最冷启动的场景：数据库一张表还没有，应用代码刚初始化，测试环境完全空白，你要从零把“建表 - 造数 - CRUD 验证”整条链路跑通。这个场景比很多人想象中更常见，尤其是新项目立项、老系统重构、或者大版本 R&D 测试环境重建的时候。
冷启动最难受的地方在于：生产数据拿不到（合规要求）、历史备份用不上（结构早就变了）、网上公开数据集又对不上业务语义。所以唯一可靠的路就是自己动手，从 DDL 开始一步步把数据和环境“种”出来。这篇文章我不聊虚的，把我自己从一张空表到 CRUD 全部跑通的过程中踩过的坑、验证过的做法、改进过的流程完整写出来。
1. 冷启动的典型场景：不是我非要折腾，而是生产数据真的拿不到
1.1 为什么测试环境经常是一片空白
很多没有经历过冷启动的人会下意识觉得：“测试环境嘛，从生产库导一份脱敏数据过来不就行了？”理论上是这样，但实际执行时会遇到一堆让你放弃的理由：
- 生产库结构已经迭代了十几次，测试库的 schema 还停留在两年前，导数据前得先升级结构，等于顺带做一次迁移演练。
- 数据脱敏不是简单把姓名和手机号替换掉，用户表里的注册时间分布、订单表里的金额分布、状态字段的枚举比例，对测试结果都有影响。脱敏工具处理不了这么细的业务语义。
- 很多系统有多套环境：dev、test、staging、以及留给外部联调的 sandbox。没有哪套环境的数据是完整可用的，每套环境都在将就。
- 有时候你连生产库的访问权限都没有，特别是涉及第三方接口联调的模块，合作方给的数据就几张 Excel，字段名还是他们自己定义的。
这种时候，冷启动就是唯一选项。所谓冷启动，不是拿官方示例数据库顶一下就算完，而是要让测试环境的数据在业务语义上“立得住”。比如电商系统，用户、商品、订单、支付流水这几张核心表的数据关系必须闭环，你写一个“查询用户半年内已支付订单明细”的用例，如果订单表里压根没有半年内支付的记录，这个用例怎么跑都是空的。
1.2 冷启动的正确打开顺序
我在实际项目中摸索出的顺序是：先设计实体关系，再写建表 SQL，然后按依赖顺序造数，最后才是 CRUD 验证。这个顺序不可逆，原因很简单：造数脚本依赖表结构，表结构依赖关系模型，关系模型又依赖业务需求。如果你连一张订单表应该有哪几个外键都没想清楚就开始 CREATE TABLE，后面造数时一定会遇到“子表记录找不到父表”的尴尬。
另外有一个容易被忽略的点：冷启动不光是“把数据搞出来”，还包括验证这套结构能不能支持业务跑通。所以我后面会专门讲 CRUD 验证，那是冷启动收尾中最能发现问题的一步，但很多人只做到“建完表、插几条数据、SELECT 一下”就结束了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 建表前置功课：先把 1:1、1:N、M:N 关系定下来，再写 DDL
2.1 关系模式如何落成建表规则
做冷启动最大的忌讳是拿到需求文档就开始写 CREATE TABLE。必须先做一件事：把所有业务实体之间的关联方式标出来。热词里提到“1:1、1:多、多:多联系的关系模式单独建表”，这个“单独建表”不是拍脑袋定的，而是三种关系各有各的落表套路。
我自己习惯用一个简单的表格来梳理：
| 关系类型 | 落表策略 | 外键放哪 | 典型场景 |
|---|---|---|---|
| 1:1 | 大多可以合并成一张表，或者拆成用户主表和用户扩展表 | 外键放在任意一侧，通常放在访问频率低的那侧 | 用户表 + 用户隐私信息扩展表 |
| 1:N | 不额外建表，父表一条对应子表多条 | 外键必须放在 N 侧（子表） | 用户与订单、文章与评论 |
| M:N | 必须单独建中间表，中间表只存关系 | 中间表持有两侧外键，通常做成联合主键 | 文章与标签、用户与角色 |
为什么 1:N 的外键必须放在 N 侧？因为如果放在 1 侧（父表），一张用户表得有多少个字段来存订单 ID？根本无法建模。而 M:N 如果不单独建中间表，就只能把多个关联 ID 塞进一个列表字段里，那后面的 JOIN 查询和关联完整性就全废了。所以“单独建表”这句话的本意是：M:N 关系必须显式落地为一张关系表，而不能用逗号分隔字段去模拟。
2.2 一个可直接抄的电商模型 DDL 示例
纸上谈兵半天，不如直接上一个我常用的示例模型。假设我们现在要冷启动一个简化版电商系统，实体包括：用户、商品分类、商品、订单、订单明细、收货地址。这些实体间的关系是这样的：用户和订单是 1:N，订单和订单明细是 1:N，商品和订单明细是 1:N，商品分类和商品是 1:N，用户和收货地址是 1:N。这里面其实没有 M:N，所以不用建中间表——如果商品有多个标签，那就需要再加一张 product_tag 关联表了。
下面是简化后的核心建表语句，我刻意把字段类型和注释都写清楚，方便直接参考：
sql复制-- 用户表
CREATE TABLE `user` (
`id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '用户ID',
`username` VARCHAR(64) NOT NULL COMMENT '登录名',
`nickname` VARCHAR(64) DEFAULT NULL COMMENT '昵称',
`phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号',
`email` VARCHAR(128) DEFAULT NULL COMMENT '邮箱',
`status` TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0禁用',
`created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
`updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户表';
-- 商品分类表
CREATE TABLE `category` (
`id` INT NOT NULL AUTO_INCREMENT,
`parent_id` INT DEFAULT NULL COMMENT '父分类ID，0为顶级分类',
`name` VARCHAR(128) NOT NULL COMMENT '分类名称',
`sort_order` INT NOT NULL DEFAULT 0,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品分类表';
-- 商品表
CREATE TABLE `product` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`category_id` INT NOT NULL COMMENT '所属分类ID',
`name` VARCHAR(256) NOT NULL,
`price` DECIMAL(10,2) NOT NULL COMMENT '单价',
`stock` INT NOT NULL DEFAULT 0,
`status` TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架',
`created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_category_id` (`category_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';
-- 订单表
CREATE TABLE `orders` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`order_no` VARCHAR(32) NOT NULL COMMENT '业务订单号',
`user_id` BIGINT NOT NULL,
`receiver_name` VARCHAR(64) NOT NULL,
`receiver_phone` VARCHAR(20) NOT NULL,
`receiver_address` VARCHAR(256) NOT NULL,
`total_amount` DECIMAL(12,2) NOT NULL,
`status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已完成 4已取消',
`paid_at` DATETIME DEFAULT NULL,
`created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_order_no` (`order_no`),
KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';
-- 订单明细表
CREATE TABLE `order_item` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`order_id` BIGINT NOT NULL,
`product_id` BIGINT NOT NULL,
`product_name` VARCHAR(256) NOT NULL COMMENT '下单时的商品快照名称',
`price` DECIMAL(10,2) NOT NULL COMMENT '下单时的商品快照单价',
`quantity` INT NOT NULL DEFAULT 1,
PRIMARY KEY (`id`),
KEY `idx_order_id` (`order_id`),
KEY `idx_product_id` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';
这里我故意保留了订单明细表里的 product_name 和 price 快照字段，这是业务上的做法：商品名称和价格可能随时改变，订单里的历史快照不能跟着变，否则金额对不上。冷启动建表时最怕只关注技术字段而忽略这种业务约束，等造数、对账的时候才发现问题。
还有一个值得注意的设计：category.parent_id 和 orders.status 注释里我明确写了枚举含义。建表阶段把字段注释写清楚，不仅能方便后面对齐，也是在给造数脚本提供“可选值范围”。
3. 建表异常实录：外键约束、字符集、自增主键的连环坑
3.1 外键建不上去的三种写法问题
很多人冷启动时真正遇到的第一道坎，不是表设计，而是外键加不上去。MySQL 里最常见的报错是 ERROR 1005: Can't create table ... errno 150 或者 ERROR 1215: Cannot add foreign key constraint。这类报错看起来像是数据库抽风，实际上十有八九是下面三类低级问题：
- 关联字段类型不一致。父表的主键是
BIGINT，子表的外键写成了INT，外键约束必然失败。这是最典型的一种。 - 关联字段的字符集或排序规则不一致。父表是
utf8mb4_unicode_ci，子表是utf8mb4_general_ci，虽然都是 utf8mb4，但 collation 不同也会卡住。 - 子表里的外键字段没有索引。InnoDB 要求外键列上必须有索引，不是主键就是普通索引。如果你在子表里建了一个外键，但对应列之前没有建索引，MySQL 在建外键时有时会自动创建，有时会直接报错。
实测下来的解决套路很固定：先执行 SHOW ENGINE INNODB STATUS\G 查看最近一次外键失败的具体信息，再对照检查上面三类原因。注意，SHOW ENGINE INNODB STATUS 里的错误信息只保留最近一条，所以一定要在报错后立刻查看，中间不要执行其他 DDL 或 DML 操作。
3.2 字符集不一致导致关联查询乱码
还有一个容易被忽略的坑：表默认字符集与连接字符集不一致。你在建表时指定了 DEFAULT CHARSET=utf8mb4，但应用连接数据库时，character_set_client 还是老旧的 utf8 或 latin1，结果就是中文写入后取出来是乱码，或者模糊查询时怎么都匹配不上。
严格的验证方式是建完表后手动执行三条 SQL：
sql复制SHOW VARIABLES LIKE 'character_set_database';
SHOW VARIABLES LIKE 'character_set_connection';
SHOW VARIABLES LIKE 'collation_connection';
如果发现变量不一致，立刻在连接串里显式带上字符集参数，比如 JDBC 连接串加 characterEncoding=utf8，或 MySQL 命令行加 --default-character-set=utf8mb4，不要依赖数据库侧的默认值。
3.3 自增主键：手动指定后引发的连锁反应
自增主键在冷启动阶段特别容易出问题。最常见的是这么一种操作：表刚建完，测试人员手工插入了几条数据，并手动指定了主键值，比如 INSERT INTO user (id, username) VALUES (100, 'test')。这几条数据测完没清理，然后真正的造数脚本开始批量 INSERT，脚本里没指定主键字段，MySQL 会在当前 AUTO_INCREMENT 值的基础上继续递增。
理论上这不算错，但如果手工插入的主键值很大——比如 10086，那后面所有正常插入的用户主键都会从 10087 开始跳着走，订单表的 user_id 也会跟着变大，整个测试数据怎么看怎么别扭。
更麻烦的是另一种场景：你把一批数据导出再导入，导入时保留了原来的主键值，但 AUTO_INCREMENT 计数没有跟着更新。后续插入的新数据主键可能会与已导入的数据主键冲突。这种情况下要手动调整自增起始值：
sql复制ALTER TABLE `user` AUTO_INCREMENT = 100001;
或者，更省心的办法是：造数脚本里不指定主键，让自增值自然增长，并且造数完成后把两张核心表的当前值清零或重置到固定值。总之，冷启动阶段的自增主键必须是可控的，不能让那些调试时随手插入的脏数据污染整套数据的编号体系。
4. 生成测试数据：先造父表再造子表，让关联字段经得起查
4.1 造数脚本的基本逻辑：字段语义优先于随机值
表结构跑通之后，进入最关键的部分：造数。这里我想纠正一个普遍误区——很多人写造数脚本就是一个大循环往每张表里插随机值，觉得“数据量够大就行”。但这样造出来的数据，你用它跑通流程没问题，一遇到稍微带点业务判断的查询就会露馅。
好的造数脚本应该是“语义优先”的。什么意思？举个例子，订单状态字段 status，取值范围是 0 到 4，每个状态在业务闭环中对应不同的时间节点。如果你随机生成，可能 90% 的订单都是“已支付”状态，而“已取消”和“已完成”的订单比例完全失真。再比如 paid_at 时间字段，一个 2020 年创建的订单，paid_at 竟然是本月时间，这在业务上就不成立。
我在实际造数时用过几个小技巧：
- 用 Python 的
random.choices配合权重来模拟枚举分布，让每种枚举值都以真实业务的比例出现。 - 时间字段的生成要克制，先设置一个时间锚点，再按偏移量生成，避免出现“未来时间”“时间早于创建时间”这类逻辑矛盾。
- 敏感字段（手机号、邮箱、地址）不用真实数据，直接格式化成可模板拼接的测试数据，比如手机号统一用
13x0000xxxx这种模式。
4.2 批量插入时外键检查的开关策略
关联表造数必须严格按依赖顺序：先父表，后子表。如果你把用户表、商品表、订单表、订单明细表的造数脚本按顺序串起来，正常情况下一遍就能过。但有个性能优化的问题：如果有几十万条订单明细，逐条 INSERT 会很慢，这时可以临时关闭外键检查。
sql复制SET FOREIGN_KEY_CHECKS = 0;
-- 批量执行 INSERT
SET FOREIGN_KEY_CHECKS = 1;
这不是让你跳过外键约束，而是为了提升批量装载性能。但注意，关闭外键检查后，如果脚本里有插入孤儿记录的 bug，它是不会立刻报错的，造数完成后一定要做一次关联完整性校验。我的习惯是：造数完把 FOREIGN_KEY_CHECKS 恢复为 1，然后手动跑几条校验 SQL，见下面 4.3。
4.3 造数后必须做的三种校验
造完数不代表完事，我每次冷启动都会跑下面这三类校验，任何一类不过，宁可清库重来也不带病进 CRUD 验证。
第一类是记录数校验：
sql复制SELECT 'user' AS tbl, COUNT(*) AS cnt FROM user
UNION ALL
SELECT 'product', COUNT(*) FROM product
UNION ALL
SELECT 'orders', COUNT(*) FROM orders
UNION ALL
SELECT 'order_item', COUNT(*) FROM order_item;
第二类是关联完整性校验，比如查一下“找不到父表的孤儿订单明细”：
sql复制SELECT oi.id
FROM order_item oi
LEFT JOIN orders o ON oi.order_id = o.id
WHERE o.id IS NULL;
第三类是业务口径校验，防止“有订单没明细”“订单金额与明细金额不一致”：
sql复制SELECT o.id,
o.total_amount,
SUM(oi.price * oi.quantity) AS calc_amount
FROM orders o
JOIN order_item oi ON oi.order_id = o.id
GROUP BY o.id, o.total_amount
HAVING o.total_amount != calc_amount;
这三条 SQL 一个都不能少，尤其是第三条，它检查的不光是数据完整性，还验证了表设计里的金额快照逻辑是否正确。设计阶段埋下的雷，在这一步基本都能炸出来。
5. CRUD 冷启动验证：只跑通流程不算数，异常分支也要验
5.1 C 与 R：从插入冲突到 JOIN 结果核验
冷启动的最后一个阶段是 CRUD 验证。注意，这里不是“写个 select 查一下有没有数据”就完了，而是要把新增、查询、更新、删除四种操作沿着业务链路完整走一遍，重点关注异常分支。
C（Create）阶段重点测试两类问题：外键约束是否真能拦截非法插入，唯一索引是否真能挡住重复值。我见过太多表设计时加了 UNIQUE KEY，但造数时数据本身有重复，结果测试环境一直没暴露问题，直到联调时才发现。所以这一步要刻意插入几条不符合约束的数据，验证约束真实生效：
sql复制-- 预期会失败：重复的用户名
INSERT INTO user (username, nickname) VALUES ('dup_user', '重复用户');
INSERT INTO user (username, nickname) VALUES ('dup_user', '重复用户二号');
-- 预期会失败：引用不存在的用户ID创建订单
INSERT INTO orders (order_no, user_id, total_amount) VALUES ('NO_TEST_FAIL', 999999, 10.00);
R（Read）阶段除了跑通最简单的 SELECT * FROM order_item WHERE order_id = ? 之外，一定要做 JOIN 查询，还要用 EXPLAIN 看一下索引有没有生效。冷启动造的数据往往量不大，量小时 MySQL 优化器可能选择全表扫单表扫，但这不代表你写的索引真的被用上了。把随机查询改成用户视角的查询：查某用户最近 30 天的订单、查某商品 30 天内的销量柱状图，这类联表 SQL 一旦跑通，说明外键关联的设计是站得住的。
5.2 U 与 D：级联行为测试和残留孤儿数据检查
U（Update）阶段经常被人忽略，但这里最容易暴露设计缺陷。比如更新用户表的主键 ID——虽然业务上极少这么做，但在测试环境里就要验证外键约束的默认行为。InnoDB 默认是 RESTRICT，会阻止你修改被引用的父表主键；而如果你建表时写了 ON UPDATE CASCADE，则关联子表会同步更新。两种行为没有绝对对错，但你得知道自己建的是哪种：
sql复制-- 这种更新应该被阻止
UPDATE user SET id = 888 WHERE id = 1;
D（Delete）阶段更关键。很多人建表时不写 ON DELETE CASCADE，导致删除用户时如果有订单存在，删除会被外键约束挡住。这在业务上可能是故意的，但也可能是建表时忘记了。冷启动验证里必须明确两种删除路径：
- 正常业务删除：先删子表，再删父表。比如先删订单明细，再删订单，再删用户。
- 级联删除：如果你希望“删用户时他的所有订单和订单明细一并删除”，那就需要在外键上声明
ON DELETE CASCADE，并验证级联确实发生。
我个人的建议是：最核心的“审计类数据”（订单、支付流水）不要用级联删除，逻辑删除比物理删除更安全。如果是临时测试数据，允许物理删除，但要注意不能留下孤儿记录。最后再跑一遍 4.3 里的孤儿数据校验 SQL，确认删除操作没有破坏关联完整性。
6. 一套可以照抄的冷启动脚本流程（个人经验版）
讲了这么多理论，最后分享一套我实际项目里用得很顺的冷启动脚本流程，希望能给有同样需求的朋友一个可直接搬走的模板。
整个流程我用 Shell 脚本串起来，分四步走：
bash复制#!/bin/bash
# 冷启动一整套流程：假设已进入 MySQL 命令行或使用 mysql 客户端执行
echo "===== 1. 初始化：清空旧表（谨慎使用，测试环境专用） ====="
mysql -uroot -pTest123 -e "SET FOREIGN_KEY_CHECKS=0; DROP TABLE IF EXISTS order_item, orders, product, category, user; SET FOREIGN_KEY_CHECKS=1;"
echo "===== 2. 建表：执行 DDL ====="
mysql -uroot -pTest123 -e "source /path/to/schema.sql"
echo "===== 3. 造数：执行 Python 或 SQL 脚本 ====="
python3 /path/to/gen_fake_data.py
echo "===== 4. 校验：关联完整性与业务口径 ====="
mysql -uroot -pTest123 -e "
SELECT COUNT(*) FROM user;
SELECT COUNT(*) FROM orders;
SELECT COUNT(*) FROM order_item;
SELECT oi.id FROM order_item oi LEFT JOIN orders o ON oi.order_id = o.id WHERE o.id IS NULL;
"
这里有两个细节要交代。第一，清空旧表时先 SET FOREIGN_KEY_CHECKS=0 再 DROP，否则如果表之间存在外键引用，DROO 顺序不对就会报错。第二，造数脚本一定要写成一个独立的可执行文件，不要直接复制粘贴到数据库客户端里执行，因为文件可以纳入版本管理，下次环境重建时还能复用，而且能看到历史修改记录。
第 3 步造数脚本我习惯用 Python 写，因为它处理复杂逻辑比纯 SQL 方便。简单结构长这样：
python复制import random
import pymysql
from datetime import datetime, timedelta
conn = pymysql.connect(host='127.0.0.1', user='root', password='Test123',
database='shop', charset='utf8mb4')
cursor = conn.cursor()
# 先造用户
user_ids = []
for i in range(100):
username = f"user_{i:04d}"
cursor.execute(
"INSERT INTO user (username, nickname, phone, status) VALUES (%s, %s, %s, %s)",
(username, f"测试用户{i}", f"13{random.randint(100000000, 999999999)}",
1 if i % 5 != 0 else 0)
)
user_ids.append(cursor.lastrowid)
# 再造商品分类和商品
category_ids = []
for i in range(10):
cursor.execute("INSERT INTO category (parent_id, name) VALUES (0, %s)", (f"分类{i}",))
category_ids.append(cursor.lastrowid)
product_ids = []
for cid in category_ids:
for _ in range(20):
cursor.execute(
"INSERT INTO product (category_id, name, price, stock, status) VALUES (%s, %s, %s, %s, %s)",
(cid, f"商品-{cid}-{_}",
round(random.uniform(10, 1000), 2),
random.randint(0, 500),
1 if random.random() > 0.1 else 0)
)
product_ids.append(cursor.lastrowid)
# 最后造订单和订单明细
for uid in user_ids:
order_count = random.randint(0, 5)
for _ in range(order_count):
cursor.execute(
"INSERT INTO orders (order_no, user_id, receiver_name, receiver_phone, receiver_address, total_amount, status) "
"VALUES (%s, %s, %s, %s, %s, %s, %s)",
(f"NO{datetime.now().strftime('%Y%m%d%H%M%S')}{random.randint(1000,9999)}",
uid, f"收货人{uid}", f"13{random.randint(100000000, 999999999)}",
f"测试地址{uid}", 0,
random.choices([0,1,2,3,4], weights=[3,3,2,1,1])[0])
)
order_id = cursor.lastrowid
detail_total = 0
for item_pid in random.sample(product_ids, random.randint(1, 5)):
price = round(random.uniform(10, 500), 2)
quantity = random.randint(1, 3)
detail_total += price * quantity
cursor.execute(
"INSERT INTO order_item (order_id, product_id, product_name, price, quantity) "
"VALUES (%s, %s, %s, %s, %s)",
(order_id, item_pid, f"商品-{item_pid}", price, quantity)
)
cursor.execute("UPDATE orders SET total_amount = %s WHERE id = %s", (round(detail_total,2), order_id))
conn.commit()
cursor.close()
conn.close()
这段脚本随手写的，具体字段和业务口径可以按自己场景改，但核心思路是：按 user → category → product → orders → order_item 的顺序造数，每层都用上一层生成出来的真实 ID 做关联。注意我在插入订单后立刻回 lastrowid 拿自增 ID，再插入明细并计算明细总额回填订单金额，这样 4.3 里的金额校验就一定能通过。
个人经验里还有一个容易被忽略的点：造数脚本一定要做幂等处理。同一个脚本跑第二次时，表里已经有数据了，主键冲突、唯一索引冲突都会冒出来。好的做法是在脚本开头先清理本次会涉及的表，或者设置一个“是否清空”的参数。我在脚本里一般是先 TRUNCATE 相关表再插入，保证重复执行不会越跑越脏。
写完之后的唠叨
冷启动这事，看起来就是把建表、造数、CRUD 过一遍，但实际做起来每一步都可能卡你一下。建表卡在外键和字符集，造数卡在字段语义和关联顺序，CRUD 验证卡在异常分支和级联行为。这些坑不是靠背文档能避开的，得亲手踩一遍，把流程固化成脚本和校验 SQL，以后每次环境重建直接复用，才能把冷启动从“每隔几个月折腾一次”变成“一条命令跑完”。
如果看完这篇对你有帮助，最值得记住的一句话是：冷启动的目标不是“有数据可查”，而是“数据经得起业务逻辑的拷问”。# 生成测试数据（三）：从建表到 CRUD 的冷启动
先交代下背景。这是"生成测试数据"这个系列的第三篇。前两篇一篇在聊"造数据前先想清楚测试目标"，一篇在讲"数据脱敏和脱敏后的可用性"，这篇直接落到最冷启动的场景：数据库一张表还没有，应用代码刚初始化，测试环境完全空白，你要从零把"建表 - 造数 - CRUD 验证"整条链路跑通。这个场景比很多人想象中更常见，尤其是新项目立项、老系统重构、或者大版本测试环境重建的时候。
冷启动最难受的地方在于：生产数据拿不到（合规要求）、历史备份用不上（结构早就变了）、网上公开数据集又对不上业务语义。所以唯一可靠的路就是自己动手，从 DDL 开始一步步把数据和环境"种"出来。这篇文章我不聊虚的，把我自己从一张空表到 CRUD 全部跑通的过程中踩过的坑、验证过的做法、改进过的流程完整写出来。
1. 冷启动的典型场景：不是我非要折腾，而是生产数据真的拿不到
1.1 为什么测试环境经常是一片空白
很多没有经历过冷启动的人会下意识觉得："测试环境嘛，从生产库导一份脱敏数据过来不就行了？"理论上是这样，但实际执行时会遇到一堆让你放弃的理由：
- 生产库结构已经迭代了十几次，测试库的表结构还停留在两年前，导数据前得先升级结构，等于顺带做一次迁移演练。
- 数据脱敏不是简单把姓名和手机号替换掉，用户表里的注册时间分布、订单表里的金额分布、状态字段的枚举比例，对测试结果都有影响。脱敏工具处理不了这么细的业务语义。
- 很多系统有多套环境：dev、test、staging、以及留给外部联调的 sandbox。没有哪套环境的数据是完整可用的，每套环境都在将就。
- 有时候你连生产库的访问权限都没有，特别是涉及第三方接口联调的模块，合作方给的数据就几张 Excel，字段名还是他们自己定义的。
这种时候，冷启动就是唯一选项。所谓冷启动，不是拿官方示例数据库顶一下就算完，而是要让测试环境的数据在业务语义上"立得住"。比如电商系统，用户、商品、订单、支付流水这几张核心表的数据关系必须闭环，你写一个"查询用户半年内已支付订单明细"的用例，如果订单表里压根没有半年内支付的记录，这个用例怎么跑都是空的。
1.2 冷启动的正确打开顺序
我在实际项目中摸索出的顺序是：先设计实体关系，再写建表 SQL，然后按依赖顺序造数，最后才是 CRUD 验证。这个顺序不可逆，原因很简单：造数脚本依赖表结构，表结构依赖关系模型，关系模型又依赖业务需求。如果你连一张订单表应该有哪几个外键都没想清楚就开始 CREATE TABLE，后面造数时一定会遇到"子表记录找不到父表"的尴尬。
另外有一个容易被忽略的点：冷启动不光是"把数据搞出来"，还包括验证这套结构能不能支持业务跑通。所以我后面会专门讲 CRUD 验证，那是冷启动收尾中最能发现问题的一步，但很多人只做到"建完表、插几条数据、SELECT 一下"就结束了。
2. 建表前置功课：先把 1:1、1:N、M:N 关系定下来，再写 DDL
2.1 关系模式如何落成建表规则
做冷启动最大的忌讳是拿到需求文档就开始写 CREATE TABLE。必须先做一件事：把所有业务实体之间的关联方式标出来。热词里提到"1:1、1:多、多:多联系的关系模式单独建表"，这个"单独建表"不是拍脑袋定的，而是三种关系各有各的落表套路。
我自己习惯用一个简单的表格来梳理：
| 关系类型 | 落表策略 | 外键放哪 | 典型场景 |
|---|---|---|---|
| 1:1 | 大多可以合并成一张表，或者拆成用户主表和用户扩展表 | 外键放在任意一侧，通常放在访问频率低的那侧 | 用户表 + 用户隐私信息扩展表 |
| 1:N | 不额外建表，父表一条对应子表多条 | 外键必须放在 N 侧（子表） | 用户与订单、文章与评论 |
| M:N | 必须单独建中间表，中间表只存关系 | 中间表持有两侧外键，通常做成联合主键 | 文章与标签、用户与角色 |
为什么 1:N 的外键必须放在 N 侧？因为如果放在 1 侧（父表），一张用户表得有多少个字段来存订单 ID？根本无法建模。而 M:N 如果不单独建中间表，就只能把多个关联 ID 塞进一个列表字段里，那后面的 JOIN 查询和关联完整性就全废了。所以"单独建表"这句话的本意是：M:N 关系必须显式落地为一张关系表，而不能用逗号分隔字段去模拟。
2.2 一个可直接抄的电商模型 DDL 示例
纸上谈兵半天，不如直接上一个我常用的示例模型。假设我们现在要冷启动一个简化版电商系统，实体包括：用户、商品分类、商品、订单、订单明细、收货地址。这些实体间的关系是这样的：用户和订单是 1:N，订单和订单明细是 1:N，商品和订单明细是 1:N，商品分类和商品是 1:N，用户和收货地址是 1:N。这里面其实没有 M:N，所以不用建中间表——如果商品有多个标签，那就需要再加一张 product_tag 关联表了。
下面是简化后的核心建表语句，我刻意把字段类型和注释都写清楚，方便直接参考：
sql复制-- 用户表
CREATE TABLE `user` (
`id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '用户ID',
`username` VARCHAR(64) NOT NULL COMMENT '登录名',
`nickname` VARCHAR(64) DEFAULT NULL COMMENT '昵称',
`phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号',
`email` VARCHAR(128) DEFAULT NULL COMMENT '邮箱',
`status` TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0禁用',
`created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
`updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户表';
-- 商品分类表
CREATE TABLE `category` (
`id` INT NOT NULL AUTO_INCREMENT,
`parent_id` INT DEFAULT NULL COMMENT '父分类ID，0为顶级分类',
`name` VARCHAR(128) NOT NULL COMMENT '分类名称',
`sort_order` INT NOT NULL DEFAULT 0,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品分类表';
-- 商品表
CREATE TABLE `product` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`category_id` INT NOT NULL COMMENT '所属分类ID',
`name` VARCHAR(256) NOT NULL,
`price` DECIMAL(10,2) NOT NULL COMMENT '单价',
`stock` INT NOT NULL DEFAULT 0,
`status` TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架',
`created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_category_id` (`category_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';
-- 订单表
CREATE TABLE `orders` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`order_no` VARCHAR(32) NOT NULL COMMENT '业务订单号',
`user_id` BIGINT NOT NULL,
`receiver_name` VARCHAR(64) NOT NULL,
`receiver_phone` VARCHAR(20) NOT NULL,
`receiver_address` VARCHAR(256) NOT NULL,
`total_amount` DECIMAL(12,2) NOT NULL,
`status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已完成 4已取消',
`paid_at` DATETIME DEFAULT NULL,
`created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_order_no` (`order_no`),
KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';
-- 订单明细表
CREATE TABLE `order_item` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`order_id` BIGINT NOT NULL,
`product_id` BIGINT NOT NULL,
`product_name` VARCHAR(256) NOT NULL COMMENT '下单时的商品快照名称',
`price` DECIMAL(10,2) NOT NULL COMMENT '下单时的商品快照单价',
`quantity` INT NOT NULL DEFAULT 1,
PRIMARY KEY (`id`),
KEY `idx_order_id` (`order_id`),
KEY `idx_product_id` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';
这里我故意保留了订单明细表里的 product_name 和 price 快照字段，这是业务上的做法：商品名称和价格可能随时改变，订单里的历史快照不能跟着变，否则金额对不上。冷启动建表时最怕只关注技术字段而忽略这种业务约束，等造数、对账的时候才发现问题。
还有一个值得注意的设计：category.parent_id 和 orders.status 注释里我明确写了枚举含义。建表阶段把字段注释写清楚，不仅能方便后面对齐，也是在给造数脚本提供"可选值范围"。
3. 建表异常实录：外键约束、字符集、自增主键的连环坑
3.1 外键建不上去的三种写法问题
很多人冷启动时真正遇到的第一道坎，不是表设计，而是外键加不上去。MySQL 里最常见的报错是 ERROR 1005: Can't create table ... errno 150 或者 ERROR 1215: Cannot add foreign key constraint。这类报错看起来像是数据库抽风，实际上十有八九是下面三类低级问题：
- 关联字段类型不一致。父表的主键是
BIGINT，子表的外键写成了INT，外键约束必然失败。这是最典型的一种。 - 关联字段的字符集或排序规则不一致。父表是
utf8mb4_unicode_ci，子表是utf8mb4_general_ci，虽然都是 utf8mb4，但 collation 不同也会卡住。 - 子表里的外键字段没有索引。InnoDB 要求外键列上必须有索引，不是主键就是普通索引。如果你在子表里建了一个外键，但对应列之前没有建索引，MySQL 在建外键时有时会自动创建，有时会直接报错。
实测下来的解决套路很固定：先执行 SHOW ENGINE INNODB STATUS\G 查看最近一次外键失败的具体信息，再对照检查上面三类原因。注意，SHOW ENGINE INNODB STATUS 里的错误信息只保留最近一条，所以一定要在报错后立刻查看，中间不要执行其他 DDL 或 DML 操作。
3.2 字符集不一致导致关联查询乱码
还有一个容易被忽略的坑：表默认字符集与连接字符集不一致。你在建表时指定了 DEFAULT CHARSET=utf8mb4，但应用连接数据库时，character_set_client 还是老旧的 utf8 或 latin1，结果就是中文写入后取出来是乱码，或者模糊查询时怎么都匹配不上。
严格的验证方式是建完表后手动执行三条 SQL：
sql复制SHOW VARIABLES LIKE 'character_set_database';
SHOW VARIABLES LIKE 'character_set_connection';
SHOW VARIABLES LIKE 'collation_connection';
如果发现变量不一致，立刻在连接串里显式带上字符集参数，比如 JDBC 连接串加 characterEncoding=utf8，或 MySQL 命令行加 --default-character-set=utf8mb4，不要依赖数据库侧的默认值。
3.3 自增主键：手动指定后引发的连锁反应
自增主键在冷启动阶段特别容易出问题。最常见的是这么一种操作：表刚建完，测试人员手工插入了几条数据，并手动指定了主键值，比如 INSERT INTO user (id, username) VALUES (100, 'test')。这几条数据测完没清理，然后真正的造数脚本开始批量 INSERT，脚本里没指定主键字段，MySQL 会在当前 AUTO_INCREMENT 值的基础上继续递增。
理论上这不算错，但如果手工插入的主键值很大——比如 10086，那后面所有正常插入的用户主键都会从 10087 开始跳着走，订单表的 user_id 也会跟着变大，整个测试数据怎么看怎么别扭。
更麻烦的是另一种场景：你把一批数据导出再导入，导入时保留了原来的主键值，但 AUTO_INCREMENT 计数没有跟着更新。后续插入的新数据主键可能会与已导入的数据主键冲突。这种情况下要手动调整自增起始值：
sql复制ALTER TABLE `user` AUTO_INCREMENT = 100001;
或者，更省心的办法是：造数脚本里不指定主键，让自增值自然增长，并且造数完成后把两张核心表的当前值清零或重置到固定值。总之，冷启动阶段的自增主键必须是可控的，不能让那些调试时随手插入的脏数据污染整套数据的编号体系。
4. 生成测试数据：先造父表再造子表，让关联字段经得起查
4.1 造数脚本的基本逻辑：字段语义优先于随机值
表结构跑通之后，进入最关键的部分：造数。这里我想纠正一个普遍误区——很多人写造数脚本就是一个大循环往每张表里插随机值，觉得"数据量够大就行"。但这样造出来的数据，你用它跑通流程没问题，一遇到稍微带点业务判断的查询就会露馅。
好的造数脚本应该是"语义优先"的。什么意思？举个例子，订单状态字段 status，取值范围是 0 到 4，每个状态在业务闭环中对应不同的时间节点。如果你随机生成，可能 90% 的订单都是"已支付"状态，而"已取消"和"已完成"的订单比例完全失真。再比如 paid_at 时间字段，一个 2020 年创建的订单，paid_at 竟然是本月时间，这在业务上就不成立。
我在实际造数时用过几个小技巧：
- 用 Python 的
random.choices配合权重来模拟枚举分布，让每种枚举值都以真实业务的比例出现。 - 时间字段的生成要克制，先设置一个时间锚点，再按偏移量生成，避免出现"未来时间""时间早于创建时间"这类逻辑矛盾。
- 敏感字段（手机号、邮箱、地址）不用真实数据，直接格式化成可模板拼接的测试数据，比如手机号统一用
13x0000xxxx这种模式。
4.2 批量插入时外键检查的开关策略
关联表造数必须严格按依赖顺序：先父表，后子表。如果你把用户表、商品表、订单表、订单明细表的造数脚本按顺序串起来，正常情况下一遍就能过。但有个性能优化的问题：如果有几十万条订单明细，逐条 INSERT 会很慢，这时可以临时关闭外键检查。
sql复制SET FOREIGN_KEY_CHECKS = 0;
-- 批量执行 INSERT
SET FOREIGN_KEY_CHECKS = 1;
这不是让你跳过外键约束，而是为了提升批量装载性能。但注意，关闭外键检查后，如果脚本里有插入孤儿记录的 bug，它是不会立刻报错的，造数完成后一定要做一次关联完整性校验。我的习惯是：造数完把 FOREIGN_KEY_CHECKS 恢复为 1，然后手动跑几条校验 SQL，见下面 4.3。
4.3 造数后必须做的三种校验
造完数不代表完事，我每次冷启动都会跑下面这三类校验，任何一类不过，宁可清库重来也不带病进 CRUD 验证。
第一类是记录数校验：
sql复制SELECT 'user' AS tbl, COUNT(*) AS cnt FROM user
UNION ALL
SELECT 'product', COUNT(*) FROM product
UNION ALL
SELECT 'orders', COUNT(*) FROM orders
UNION ALL
SELECT 'order_item', COUNT(*) FROM order_item;
第二类是关联完整性校验，比如查一下"找不到父表的孤儿订单明细"：
sql复制SELECT oi.id
FROM order_item oi
LEFT JOIN orders o ON oi.order_id = o.id
WHERE o.id IS NULL;
第三类是业务口径校验，防止"有订单没明细""订单金额与明细金额不一致"：
sql复制SELECT o.id,
o.total_amount,
SUM(oi.price * oi.quantity) AS calc_amount
FROM orders o
JOIN order_item oi ON oi.order_id = o.id
GROUP BY o.id, o.total_amount
HAVING o.total_amount != calc_amount;
这三条 SQL 一个都不能少，尤其是第三条，它检查的不光是数据完整性，还验证了表设计里的金额快照逻辑是否正确。设计阶段埋下的雷，在这一步基本都能炸出来。
5. CRUD 冷启动验证：只跑通流程不算数，异常分支也要验
5.1 C 与 R：从插入冲突到 JOIN 结果核验
冷启动的最后一个阶段是 CRUD 验证。注意，这里不是"写个 select 查一下有没有数据"就完了，而是要把新增、查询、更新、删除四种操作沿着业务链路完整走一遍，重点关注异常分支。
C（Create）阶段重点测试两类问题：外键约束是否真能拦截非法插入，唯一索引是否真能挡住重复值。我见过太多表设计时加了 UNIQUE KEY，但造数时数据本身有重复，结果测试环境一直没暴露问题，直到联调时才发现。所以这一步要刻意插入几条不符合约束的数据，验证约束真实生效：
sql复制-- 预期会失败：重复的用户名
INSERT INTO user (username, nickname) VALUES ('dup_user', '重复用户');
INSERT INTO user (username, nickname) VALUES ('dup_user', '重复用户二号');
-- 预期会失败：引用不存在的用户ID创建订单
INSERT INTO orders (order_no, user_id, total_amount) VALUES ('NO_TEST_FAIL', 999999, 10.00);
R（Read）阶段除了跑通最简单的 SELECT * FROM order_item WHERE order_id = ? 之外，一定要做 JOIN 查询，还要用 EXPLAIN 看一下索引有没有生效。冷启动造的数据往往量不大，量小时 MySQL 优化器可能选择全表扫单表扫，但这不代表你写的索引真的被用上了。把随机查询改成用户视角的查询：查某用户最近 30 天的订单、查某商品 30 天内的销量柱状图，这类联表 SQL 一旦跑通，说明外键关联的设计是站得住的。
5.2 U 与 D：级联行为测试和残留孤儿数据检查
U（Update）阶段经常被人忽略，但这里最容易暴露设计缺陷。比如更新用户表的主键 ID——虽然业务上极少这么做，但在测试环境里就要验证外键约束的默认行为。InnoDB 默认是 RESTRICT，会阻止你修改被引用的父表主键；而如果你建表时写了 ON UPDATE CASCADE，则关联子表会同步更新。两种行为没有绝对对错，但你得知道自己建的是哪种：
sql复制-- 这种更新应该被阻止
UPDATE user SET id = 888 WHERE id = 1;
D（Delete）阶段更关键。很多人建表时不写 ON DELETE CASCADE，导致删除用户时如果有订单存在，删除会被外键约束挡住。这在业务上可能是故意的，但也可能是建表时忘记了。冷启动验证里必须明确两种删除路径：
- 正常业务删除：先删子表，再删父表。比如先删订单明细，再删订单，再删用户。
- 级联删除：如果你希望"删用户时他的所有订单和订单明细一并删除"，那就需要在外键上声明
ON DELETE CASCADE，并验证级联确实发生。
我个人的建议是：最核心的"审计类数据"（订单、支付流水）不要用级联删除，逻辑删除比物理删除更安全。如果是临时测试数据，允许物理删除，但要注意不能留下孤儿记录。最后再跑一遍 4.3 里的孤儿数据校验 SQL，确认删除操作没有破坏关联完整性。
6. 一套可以照抄的冷启动脚本流程（个人经验版）
讲了这么多理论，最后分享一套我实际项目里用得很顺的冷启动脚本流程，希望能给有同样需求的朋友一个可直接搬走的模板。
整个流程我用 Shell 脚本串起来，分四步走：
bash复制#!/bin/bash
# 冷启动一整套流程：假设已进入 MySQL 命令行或使用 mysql 客户端执行
echo "===== 1. 初始化：清空旧表（谨慎使用，测试环境专用） ====="
mysql -uroot -pTest123 -e "SET FOREIGN_KEY_CHECKS=0; DROP TABLE IF EXISTS order_item, orders, product, category, user; SET FOREIGN_KEY_CHECKS=1;"
echo "===== 2. 建表：执行 DDL ====="
mysql -uroot -pTest123 -e "source /path/to/schema.sql"
echo "===== 3. 造数：执行 Python 或 SQL 脚本 ====="
python3 /path/to/gen_fake_data.py
echo "===== 4. 校验：关联完整性与业务口径 ====="
mysql -uroot -pTest123 -e "
SELECT COUNT(*) FROM user;
SELECT COUNT(*) FROM orders;
SELECT COUNT(*) FROM order_item;
SELECT oi.id FROM order_item oi LEFT JOIN orders o ON oi.order_id = o.id WHERE o.id IS NULL;
"
这里有两个细节要交代。第一，清空旧表时先 SET FOREIGN_KEY_CHECKS=0 再 DROP，否则如果表之间存在外键引用，DROP 顺序不对就会报错。第二，造数脚本一定要写成一个独立的可执行文件，不要直接复制粘贴到数据库客户端里执行，因为文件可以纳入版本管理，下次环境重建时还能复用，而且能看到历史修改记录。
第 3 步造数脚本我习惯用 Python 写，因为它处理复杂逻辑比纯 SQL 方便。简单结构长这样：
python复制import random
import pymysql
from datetime import datetime, timedelta
conn = pymysql.connect(host='127.0.0.1', user='root', password='Test123',
database='shop', charset='utf8mb4')
cursor = conn.cursor()
# 先造用户
user_ids = []
for i in range(100):
username = f"user_{i:04d}"
cursor.execute(
"INSERT INTO user (username, nickname, phone, status) VALUES (%s, %s, %s, %s)",
(username, f"测试用户{i}", f"13{random.randint(100000000, 999999999)}",
1 if i % 5 != 0 else 0)
)
user_ids.append(cursor.lastrowid)
# 再造商品分类和商品
category_ids = []
for i in range(10):
cursor.execute("INSERT INTO category (parent_id, name) VALUES (0, %s)", (f"分类{i}",))
category_ids.append(cursor.lastrowid)
product_ids = []
for cid in category_ids:
for _ in range(20):
cursor.execute(
"INSERT INTO product (category_id, name, price, stock, status) VALUES (%s, %s, %s, %s, %s)",
(cid, f"商品-{cid}-{_}",
round(random.uniform(10, 1000), 2),
random.randint(0, 500),
1 if random.random() > 0.1 else 0)
)
product_ids.append(cursor.lastrowid)
# 最后造订单和订单明细
for uid in user_ids:
order_count = random.randint(0, 5)
for _ in range(order_count):
cursor.execute(
"INSERT INTO orders (order_no, user_id, receiver_name, receiver_phone, receiver_address, total_amount, status) "
"VALUES (%s, %s, %s, %s, %s, %s, %s)",
(f"NO{datetime.now().strftime('%Y%m%d%H%M%S')}{random.randint(1000,9999)}",
uid, f"收货人{uid}", f"13{random.randint(100000000, 999999999)}",
f"测试地址{uid}", 0,
random.choices([0,1,2,3,4], weights=[3,3,2,1,1])[0])
)
order_id = cursor.lastrowid
detail_total = 0
for item_pid in random.sample(product_ids, random.randint(1, 5)):
price = round(random.uniform(10, 500), 2)
quantity = random.randint(1, 3)
detail_total += price * quantity
cursor.execute(
"INSERT INTO order_item (order_id, product_id, product_name, price, quantity) "
"VALUES (%s, %s, %s, %s, %s)",
(order_id, item_pid, f"商品-{item_pid}", price, quantity)
)
cursor.execute("UPDATE orders SET total_amount = %s WHERE id = %s", (round(detail_total,2), order_id))
conn.commit()
cursor.close()
conn.close()
这段脚本随手写的，具体字段和业务口径可以按自己场景改，但核心思路是：按 user → category → product → orders → order_item 的顺序造数，每层都用上一层生成出来的真实 ID 做关联。注意我在插入订单后立刻回 lastrowid 拿自增 ID，再插入明细并计算明细总额回填订单金额，这样 4.3 里的金额校验就一定能通过。
个人经验里还有一个容易被忽略的点：造数脚本一定要做幂等处理。同一个脚本跑第二次时，表里已经有数据了，主键冲突、唯一索引冲突都会冒出来。好的做法是在脚本开头先清理本次会涉及的表，或者设置一个"是否清空"的参数。我在脚本里一般是先 TRUNCATE 相关表再插入，保证重复执行不会越跑越脏。
写完之后的唠叨
冷启动这事，看起来就是把建表、造数、CRUD 过一遍，但实际做起来每一步都可能卡你一下。建表卡在外键和字符集，造数卡在字段语义和关联顺序，CRUD 验证卡在异常分支和级联行为。这些坑不是靠背文档能避开的，得亲手踩一遍，把流程固化成脚本和校验 SQL，以后每次环境重建直接复用，才能把冷启动从"每隔几个月折腾一次"变成"一条命令跑完"。
如果看完这篇对你有帮助，最值得记住的一句话是：冷启动的目标不是"有数据可查"，而是"数据经得起业务逻辑的拷问"。