迁移实战派01：ETL迁移基础知识-思路和规划

2026/8/4 11:02:33 拓冰建站浏览量

迁移实战派01 ETL迁移基础知识-思路和规划

一、迁移总体思路：遵循“先结构，后数据，再校验”的铁律

数据迁移就像盖楼，得先打地基（建表结构），再往上砌砖（灌数据）。根据行业最佳实践，可以分为三大阶段：

1. 准备阶段：明确迁什么、不迁什么，并完成数据类型映射。
2. 结构迁移（建表）：这是最关键的步骤。必须先建好目标表，并且要处理好表之间的依赖关系。
3. 数据迁移：利用Kettle等工具，将数据从源库导入目标表。
4. 验证阶段：迁移完成后，必须进行严格的数据校验。

二、迁移顺序：先搬字典，再搬业务，最后搬大表

这是你问的核心。一个合理的迁移顺序能避免外键报错，并方便问题排查。根据我们的表清单，建议顺序如下：

分阶段依据：

阶段一：字典/配置表（Foundation）：这些是系统的“基石”，数据量小，被其他表广泛引用。必须先迁移，否则后续业务表导入时，关联的外键会报错。
阶段二：核心业务表（Core Business）：如患者主索引、病历主索引。它们是主体数据，行数较多（如40万行），可以放在中间迁移。
阶段三：大字段/日志表（Large Objects）：如STRNEWEMR_MR_FILE_TEXT，这类表包含BLOB/CLOB，数据量大，迁移耗时且容易出错。建议放在最后，单独处理。
阶段四：关联表（Relationships）：如用户-角色关联表，这些表通常依赖前面的主数据，放在最后迁移。

三、各阶段操作详解（含SQL示例）

阶段一：迁移字典表（以`DICT_EMR_DEPT`为例）

这是你刚刚成功跑通的流程，我们把它标准化。

步骤1：在MySQL中创建表结构

USEemr_raw;CREATETABLEIFNOTEXISTSemr_dict_dept(dept_idVARCHAR(50)NOTNULLCOMMENT'科室编码',dept_nameVARCHAR(200)NOTNULLCOMMENT'科室名称',PRIMARYKEY(dept_id))ENGINE=InnoDBDEFAULTCHARSET=utf8mb4COLLATE=utf8mb4_unicode_ci;

步骤2：在Kettle中配置转换

表输入 (Oracle)：SELECT DEPT_ID, DEPT_NAME FROM POWERPLUSEMR.DICT_EMR_DEPT
表输出 (MySQL)：目标表emr_dict_dept，并做好字段映射。

步骤3：运行并验证

运行Kettle转换。
在MySQL中执行SELECT COUNT(*) FROM emr_dict_dept;，确认行数与Oracle一致（172行）。

阶段二：迁移核心业务表（以`STRNEWEMR_MR_FILE_INDEX`为例）

步骤1：在MySQL中创建表结构（关键：处理字段类型和长度）

USEemr_raw;-- 假设表结构类似，重点处理 VARCHAR2 的长度CREATETABLEIFNOTEXISTSemr_mr_index(mr_idBIGINTAUTO_INCREMENTPRIMARYKEY,mr_codeVARCHAR(50)NOTNULL,patient_idVARCHAR(50),-- 其他字段...create_date_timeDATETIME-- Oracle的DATE要转为DATETIME)ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;

步骤2：在Kettle中配置转换

表输入 (Oracle)：SELECT * FROM POWERPLUSEMR.STRNEWEMR_MR_FILE_INDEX
表输出 (MySQL)：目标表emr_mr_index，做好字段映射。

注意：此表有40万行数据，建议先在Kettle的“表输入”中使用WHERE ROWNUM <= 10000进行小批量测试，确认无误后再移除此限制。

阶段三：迁移大字段表（`STRNEWEMR_MR_FILE_TEXT`）

这是最复杂的部分，需要单独处理。

步骤1：在MySQL中创建表结构

USEemr_raw;CREATETABLEIFNOTEXISTSemr_mr_text(text_idBIGINTAUTO_INCREMENTPRIMARYKEY,mr_codeVARCHAR(50)NOTNULL,file_textLONGBLOB,-- Oracle的BLOB对应MySQL的LONGBLOB-- 其他字段...)ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;

步骤2：在Kettle中配置特殊转换

表输入 (Oracle)：SELECT MR_CODE, FILE_TEXT FROM POWERPLUSEMR.STRNEWEMR_MR_FILE_TEXT
关键：Kettle需要特殊配置以支持BLOB字段的读写。

四、迁移后的验证（数据校验）

数据迁移完成后，必须进行校验，否则上线后可能出现数据不一致的严重问题。

校验层级	校验内容	方法/工具	重要性
数量校验	对比源库和目标库每个表的总行数是否一致。	分别对Oracle和MySQL执行`SELECT COUNT(*)`，对比结果。	必须
字段校验	对关键表，抽样对比几行所有字段的值是否完全一致。	在Oracle和MySQL中查询同一主键的记录，人工或脚本对比。	强烈建议
业务校验	运行几个核心业务的查询SQL，对比结果是否一致。	执行典型的报表或查询语句，比对返回结果。	建议

五、总结：你现在的状态和接下来的路

你的状态	下一步行动
✅已打通：`DICT_EMR_DEPT`迁移链路	重复此模式，迁移阶段一剩余的字典表（如`STRNEWEMR_MENU`等）。
⏳进行中：理解迁移顺序与原理	根据阶段二的方法，开始准备`STRNEWEMR_MR_FILE_INDEX`的迁移。
📝待规划：处理大表和大字段	我们到时一起专门攻克`STRNEWEMR_MR_FILE_TEXT`这个难点。

你问的“迁移顺序”和“语句”正是整个项目最核心的技术点，我们现在已经把它梳理清楚了。接下来就按照这个路线图，一张表一张表地推进。你先继续迁移STRNEWEMR_MENU，有任何问题随时发我。

建站实战干货

迁移实战派01：ETL迁移基础知识-思路和规划