生成测试数据（三）：从建表到 CRUD 的冷启动

在前两篇中，我们分别探讨了利用 SQLynx 生成海量数据进行后端性能压测 ，以及生成边界数据进行前端 UI 适配。

每一个新项目都会经历这样一个尴尬的"真空期"：表结构刚刚设计好（CREATE TABLE 执行完毕），但代码还没写，数据库里空空如也。此时，后端想写个 CRUD 接口验证一下 SQL，前端想调个接口看看返回值结构，测试想跑个冒烟测试，所有人都在等数据。

手写 INSERT 语句不仅效率低，而且容易因为外键约束或非空限制而报错。本文将分享如何利用 SQLynx 快速打破僵局，实现从"种子数据"到"全量数据"的平滑过渡。

01 场景准备：一个需要"混合数据"的用户表

假设我们正在开发一个 SaaS 系统的用户模块，表结构如下：

复制代码

CREATE TABLE `t_sys_users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL,
  `role_type` varchar(20) NOT NULL COMMENT 'ADMIN/USER/GUEST',
  `is_active` tinyint(1) NOT NULL DEFAULT '1',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

要点：

必须有"真"数据： 我们需要至少 1 个 ADMIN 账号（如 admin/123456）用于登录系统和权限验证。这不能是随机生成的。
必须有"多"数据： 我们需要 1000 个普通 USER 账号，用于测试用户列表的分页和搜索功能。

02 核心技巧：种子数据与追加模式 (Append Mode)

在传统的自动化造数工具中，往往不仅会清空表，还会覆盖掉我们预置的管理员账号。SQLynx 的 "追加模式" 完美解决了这个问题。

第一步：预置"种子数据" (Seed Data)

首先，我们手动插入（或保留）那条至关重要的管理员数据。这是业务逻辑跑通的基石。

复制代码

INSERT INTO t_sys_users (username, role_type) VALUES ('super_admin', 'ADMIN');

第二步：配置随机"填充数据"

在 SQLynx 中右键点击 t_sys_users 表，选择 "生成测试数据"。

为了生成那 1000 个普通用户，我们做如下配置：

username： 选择 "随机字符串"。
- 注意： 由于有 UNIQUE KEY，建议长度范围设大一点（如 8-12 位），或者勾选底部的"忽略错误"，防止随机生成的用户名冲突导致任务中断。
role_type： 选择 "固定值" 或 "自定义列表"。
- 这里我们填入 USER。这样生成的 1000 人全是普通用户，不会干扰管理员逻辑。
is_active： 选择 "随机整数" ，范围 0 - 1。

第三步：选择"追加数据"策略

这是最关键的一步。在底部的"写入模式"中：

取消勾选 "清空数据"。
选择 "追加数据"。
生成数量 设置为 1000。

点击生成。几秒钟后，你的表中就拥有了 1 条真实的管理员 + 1000 条随机的普通用户。开发人员既可以登录系统，又能立刻调试分页列表，完美兼顾了逻辑验证与压力测试。

03 进阶场景：解决外键约束的"死结"

冷启动阶段另一个头疼的问题是外键约束 。比如先有 User 才能有 Order。如果直接往 Order 表生成数据，会因为 user_id 不存在而报错。

解决路径：

利用 SQLynx 的操作顺序，模拟业务发生顺序：

先对主表（t_sys_users）生成 1000 条数据。
观察主表的 ID 范围（例如 1 - 1001）。
再对子表（t_orders）生成数据。在配置 user_id 字段时，选择 "随机整数" ，并将范围严格设定为 1 - 1001。

这样生成的子表数据，在逻辑上就能"挂"到主表上，顺利绕过外键检查，让关联查询（JOIN）也能查出结果。

04 技术 Tips：随机数据的适用边界

虽然数据生成功能非常强大，但作为技术人员，我们需要清晰地认识到**随机数据（Random Data）与业务数据（Business Data）**的界限。

✅ 适合场景：

性能基准测试： 验证索引、分页、吞吐量（如系列第一篇所述）。
前端适配测试： 验证 UI 布局、溢出、特殊字符显示（如系列第二篇所述）。
冒烟测试： 验证接口通不通、数据库连没连上。

❌ 不适合场景：

复杂状态机验证： 例如订单状态从"待支付"流转到"已发货"，随机数据无法模拟这种时间与状态的严密逻辑对应。
财务报表核对： 随机生成的金额无法通过会计平衡公式（借贷相等）的校验。

最佳实践建议：

在项目开发中，建议采用**"三明治策略"**：底层用 SQLynx 生成海量随机数据作为"背景噪音"；顶层通过手工或单元测试插入少量精心构造的"业务数据"用于逻辑验证。