# 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/t_qrtz_*/debug_picture） | 可全清空或留最近少量（开发查结构无需历史） |
| 运行期 `t_picture_*` 分表 | 只保留选定培养记录关联的 picture_uuid；空分表可 drop（结构不动指逻辑表，分表是运行期产物） |

---

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

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

---

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

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

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