11 · 数据库测试数据精简方案（瘦身，便于开发查阅）

父文档：../00-需求总览.md 目标：库结构不动（开发中按需自行调结构），只把测试数据精简成少量种子数据，方便开发查库时不被海量数据淹没。 核心约束：很多表没有主外键约束，不能每表随便留 N 条——必须按业务主线保留能互相关联的整链数据，否则留下的数据断链、无意义。 ⚠️ 删数据不可逆：先备份 → 测试库演练 → 确认 → 再执行。本方案产出 SQL 脚本，由你在数据库工具执行（无库连接，不直连）。

1. 表分类（5 库全覆盖）

A. 基础/配置/字典（全留，删了系统跑不起来）

库	表
auth	`user` `role` `permission` `middle`
tl_setting	`tl_info`(设备) `tl_setting`(配置) `house`(舱配置) `house_well_setting` `house_photograph_setting` `house_collect` `alarm_type`(告警字典) `alarm_template` `alarm_permissions` `alarm_personnel` `language_configuration`(多语言) `cn_region_info`(地区)
business	`dictionary`(字典) `embryo_level` `mark` `mark_key` `mark_weight` `identify_config` `photo_search_button` `software_version`
services	`alarm_contacts`

这些是"配置/枚举/基础"，数据量本身不大，全保留，保证系统可启动、界面可用、多语言正常。

B. 业务流水（按主线精简）—— 数据膨胀的根源

库	表	说明
business	`case_info` 病例 / `embryo_culture_record` 培养记录 / `embryo` 胚胎 / `embryo_mark` `embryo_mark_splice` 标记 / `balance` 平衡	业务主体
business	`picture` 图片记录（及运行期 `t_picture_*` 分表） / `debug_picture` 调试图	图片，量最大
business	`video` `video_pictures` `video_splice` `video_update`	视频
business	`picture_identify_result` `picture_identify_middle` `picture_identify_result_cache`	AI 识别结果
business	`message` 消息 / `log` 业务日志	流水
data_transmission	`video` `video_pictures` `video_splice` `video_update`	视频（该库副本）
tl_setting	`alarm_data` 报警历史 / `alarm` / `alarm_send_info` / `environment_temperature` 环境采样 / `mqtt_message` 指令流水	流水，量大
services	`tdi_log` 系统日志	流水
框架	`system_log` / `t_qrtz_*` quartz	日志/定时，量大

2. 关联主线（没主外键，靠逻辑键串联）

业务数据靠这些逻辑关联键串起来（非数据库约束，是字段约定）：

case_info.case_id
   ▲ (case_id)
embryo_culture_record.id ────────────┐  培养记录=主线根
   ▲ embryo_culture_record_id         │ (tl_sn, house_sn)
   ├── embryo.embryo_culture_record_id│
   ├── picture.embryo_culture_record_id(+embryo_id, picture_uuid)
   ├── video.embryo_culture_record_id(+embryo_id)
   │      ▲ video_id
   │      ├── video_pictures.video_id
   │      ├── video_splice.video_id
   │      └── video_update.video_id
   ├── embryo_mark.embryo_culture_record_id(+embryo_id, picture_uuid)
   └── picture_identify_result.embryo_culture_record_id(+embryo_id, picture_uuid)

设备维度：tl_sn / house_sn 贯穿大部分表
   alarm_data / environment_temperature / message / log 按 tl_sn+house_sn 关联设备
   picture_identify_result_cache 按 picture_uuid 关联

保留策略：选 2-3 个 embryo_culture_record（培养记录）作为种子根（覆盖不同状态：培养中/已结束/已移植），顺着上面的键，把它们关联的 case_info、embryo、picture、video(+三张子表)、embryo_mark、identify_result 一并保留；其余删除。设备维度的 alarm_data/environment_temperature/message/log 按"保留的 tl_sn+house_sn + 近期时间窗"留少量。

3. 精简规则（每类怎么留）

表类	规则
主线根 `embryo_culture_record`	保留选定的 2-3 条（按 id 或状态挑）
跟随主线（embryo/picture/video*/embryo_mark/identify_result）	只保留 `embryo_culture_record_id ∈ 选定根` 的记录
case_info	只保留被选定培养记录引用的 `case_id`
设备流水（alarm_data/environment_temperature/message/log/mqtt_message）	按"选定 tl_sn+house_sn"且"近 N 条/近 X 天"保留少量
纯日志（system_log/tdi_log/tqrtz*/debug_picture）	可全清空或留最近少量（开发查结构无需历史）
运行期 `t_picture_*` 分表	只保留选定培养记录关联的 picture_uuid；空分表可 drop（结构不动指逻辑表，分表是运行期产物）

4. 执行步骤（你在数据库工具按序跑）

全量备份所有库（mysqldump 或工具导出），留回滚。
在开发库/测试库先跑，确认系统能启动、界面能查到那 2-3 个病例的完整链。
选定种子根 id（脚本里用变量），按 §3 规则先删跟随表、再删根表（避免悬挂），最后清日志表。
校验：选定病例 → 胚胎 → 图片 → 视频 → 识别结果 → 报警，链路完整、界面可展示。
配置/字典表（§1.A）一条都不删。

5. 待你拍板（定了我产出可执行 SQL 脚本）

种子根：按"2-3 个培养记录"留，对吗？还是按设备 tl_sn 留某台的全部？
保留量：培养记录留几个？设备流水（报警/环境温度）留"近多少条/几天"？
日志表：system_log/tdi_log/quartz/debug_picture 全清空，还是各留最近 N 条？
环境：仅开发库执行（可放手），确认不会碰生产？

结论：本方案只删数据、不动结构；按业务主线保留可关联的少量种子数据 + 全留配置字典。脚本待你定上面 4 点后产出。

数据库测试数据精简方案.md 5.8 KB Пермалинк Историја Датотека