# RailwaySystem 数据库 V2 应急回滚指南 (Round 1 修订版)

> **技术基线**：KingbaseES V009R003C018 (`schema=public`)  
> **回滚目标**：安全撤销 V2 数据库结构变更，将数据模型与物理约束 100% 精确还原至 Phase 0.5 历史基线。

---

## 1. 核心架构升级：解耦结构与数据

在 Round 1 审查中，彻底废除了使用 `CREATE TABLE ... AS SELECT * FROM bak_v1_*`（CTAS）推断历史结构的危险方案：

```text
┌─────────────────────────────────────────────────────────┐
│ Phase 0.5 精确物理结构 (表定义/列类型/PK/FK/UNIQUE/触发器) │
│ 来源: rollback/000_phase05_exact_schema.sql             │
└───────────────────────────┬─────────────────────────────┘
                            │ (先精确重建物理表结构)
                            ▼
┌─────────────────────────────────────────────────────────┐
│ Phase 0.5 真实数据 (唯一教师行 + 各表数据)               │
│ 来源: 001 备份生成的 bak_v1_* 快照表                    │
└───────────────────────────┬─────────────────────────────┘
                            │ (再通过 INSERT INTO 导入数据)
                            ▼
                    【Phase 0.5 绝对还原】
```

- **`000_phase05_exact_schema.sql`**：作为唯一的物理结构基准，确保回滚后恢复所有 24 个旧外键、7 组旧业务唯一约束、NOT NULL、DEFAULT、IDENTITY 序列以及 9 个 `update_time` 触发器；
- **`bak_v1_*` 快照表**：仅承担纯粹的“数据暂存”职责。

---

## 2. 回滚脚本执行顺序

若在测试迁移或灰度验证阶段发现重大异常，需按照以下严格顺序执行回滚流水线：

```text
步骤 1: 执行 001_rollback_new_tables.sql
        -> 显式解除外键依赖，安全下线并 DROP 掉 V2 新增的 8 张业务表

步骤 2: 执行 002_rollback_modified_tables.sql
        -> 基于 000_phase05_exact_schema.sql 的精确结构重建 13 张表，并从 bak_v1_* 物理快照还原数据，严格断言教师数据为 1 行

步骤 3: 执行 003_restore_legacy_score.sql
        -> 基于 000_phase05_exact_schema.sql 的精确结构重建 train_score_info 及 3 个历史外键与唯一约束

步骤 4: 人工核验 Phase 0.5 状态
        -> 执行 000_preflight.sql 校验基线恢复，确认 14 张表、触发器与约束 100% 吻合
```

---

## 3. 强前置依赖与数据来源声明

> [!CAUTION]
> **回滚操作必须满足以下前置条件：**

1. **依赖 001 备份快照**：
   - 步骤 2 与步骤 3 的数据还原依赖迁移前由 `001_backup_current_schema.sql` 生成的 `bak_v1_*` 快照表。
   - 若 `bak_v1_*` 表意外被删，**严禁盲目执行数据还原语句**。
2. **唯一教师数据的物理还原**：
   - 教师主档 `train_teacher` 的数据通过 `INSERT INTO train_teacher SELECT * FROM bak_v1_train_teacher;` 完整回灌。回滚脚本会严格校验恢复后的教师行数必须等于 1。
3. **事务安全性**：
   - 每一个回滚 SQL 文件内部均由显式 `BEGIN ... COMMIT` 包裹，出现任何错误自动整单回滚，不产生中间半回滚状态。

---

## 4. 必须人工介入确认的场景

### 场景 A：V2 阶段已产生新业务数据
如果系统在执行 V2 DDL 之后，业务端或测试端已经在 `train_enrollment`、`train_lesson`、`train_student_score` 等表中写入了新数据：
- **直接执行回滚将导致这些新业务数据彻底物理清除！**
- **必须人工介入**：先通过数据导出工具将 V2 新增业务数据导出为 CSV/JSON 归档，确认业务无异议后方可执行回滚。

### 场景 B：bak_v1_* 备份表意外缺失
若 `bak_v1_*` 表不存在：
- 必须暂停脚本执行；
- 从数据库物理备份集（如 `sys_backup` / 逻辑转储快照）中恢复 14 张旧表数据。

---

## 5. 回滚后验收确认 Checklist

回滚完成后，在数据库客户端中直接运行 `000_preflight.sql` 即可自动化完成全量反向验收：

- [ ] 1. 运行 `000_preflight.sql` 成功输出 `[Preflight-PASS]`；
- [ ] 2. 确认已无任何 V2 独有表（如 `train_plan_course` 等）；
- [ ] 3. 确认旧表 `train_score_info` 已恢复，且具备旧外键；
- [ ] 4. 确认 `train_teacher` 精确包含 1 条数据，且旧字段 `t_department` 存在且非空；
- [ ] 5. 确认 9 个旧触发器全部重新挂载生效；
- [ ] 6. 确认系统表 `sys_*` 完好无损。