导读

前文分享了平安科技如何完成从 Oracle 向 TiDB 的大规模迁移实践，涵盖选型背景、架构设计、部署架构等关键环节，本文从技术实操角度，分享实施路径以及操作指南。

作者：冼业钊｜平安科技云数据库技术专家

一、去 O 全流程实施路径分享

迁移全过程的十个关键阶段：

立项与资源准备：明确时间表、人力分工及硬件资源配置。大型项目需 4–6 个月，小型项目约 1–2 个月
迁移工具选型：主要使用自研的 TMS 工具，同时结合 sqluldr2 + Lightning 用于大表导入
搭建测试与开发环境：预先模拟验证场景，规避测试盲点
表结构梳理与兼容性转换：
1. Oracle 中未指定精度的 NUMBER 类型需转为 BIGINT 或 DECIMAL
2. Oracle 默认值函数如 SYSDATE 替换为 CURRENT_TIMESTAMP
3. 外键约束（已在 TiDB v8.5.0 GA）
4. Oracle 中 '' 与 NULL 的差异需业务逻辑配合改写
初始化数据导入：通过静态 COW 库导出，避免写入冲突。8 张大表采用拆批并发导出，提升导入效率。
流量回放与性能压测：
1. 使用 openresty 进行生产流量镜像
2. 控制模块支持流量放大倍数
3. 搭建消息隔离中间件与挡板服务
4. 比对真实与复制请求返回，验证功能一致性
性能调优：
1. 复杂 SQL 改写率高达 80%，简单业务约 30%
2. 固化执行计划、优化索引选择性
3. 调整 GC 与 compaction filter 配置，缓解 MVCC 性能瓶颈
增量同步与数据校验：OGG 或 TiCDC 同步机制，确保数据准确性
业务切换：
1. 通过触发器限制写操作权限，仅保留数据同步用户
2. 等待数据一致后，关闭 Oracle 写入，全量切换至 TiDB
回退机制：
1. 若出现异常，仅需关闭同步、撤除触发器、连接切回 Oracle，即可恢复业务
2. 操作流程简洁高效，确保业务连续性

二、平安科技国产化迁移核心技术分享

Oracle 对象梳理和表结构转换

在数据库迁移过程中，表结构和对象的处理是非常重要的一环。平安科技通常会从数据量的规模入手，来决定采用何种迁移策略与工具。例如，针对数据量较小的联系表、分析表，如果不涉及历史归档需求，通常会直接调整为普通表结构以简化迁移流程。

在实际操作中，还需特别关注字段类型的兼容问题，尤其是日期类型（如 date）和数值类型字段的转换规则。同时，需要根据表的数据规模、字段特征及业务写入方式，选择是否进行字段改造或规则重写。

在兼容性层面，一个典型的处理点在于空值的表现差异：Oracle 中空字符串（''）通常被视作 NULL，而在 TiDB 中则严格区分 NULL 和空字符串。与此同时，有些业务逻辑会在插入数据时通过引号写入空值，这种行为在 Oracle、MySQL 和 TiDB 三者之间的处理方式并不完全一致。例如，MySQL 中可能保留空字符串原值，而 TiDB 可能转为 NULL，从而导致数据比对出现不一致。

这类语义差异会直接影响数据校验、ETL 逻辑乃至业务程序行为，因此在迁移前需通过脚本或工具做额外处理，确保字段行为在新平台下的表现与原系统保持一致。

初始化数据

在迁移过程中，初始化数据是一个非常重要的环节。如果使用 TMS，它需要调用用户函数来写入一些内部数据，因此不能在数据同步过程中直接写入。在金融保险行业，不允许在未切换之前就使用目标库。因此，平安科技建立了一个静态库，多增加一个集群，将生产数据同步过去。主要使用 CPS 或 PMS 两种同步方法。在完成客户静态数据同步后，再将客户的所有数据引流到目标库，整个迁移时间大约需要两周左右。

需要注意的是，这两周的时间不包括数据不一致的情况。数据校验可能还需要额外两周时间，因此整体数据迁移大约需要一个月。在同步迁移时，一般会根据表的大小采用不同的方法。例如，大表可以使用 LOAD DATA 加 ID 的方式。在老版本中，TMS 不支持这种操作，但在新版本的 TMS 中已经支持大表的 SET LOAD 方法。此外，当遇到一些客户在异地机房内，导出数据时由于网络传输时间较长从而出现数据延迟或错误的情况，一般会通过分批处理，将大表拆小来解决这些问题。

在将表导入 TiDB 过程中可能会遇到唯一键冲突报错，这是因为 Oracle 原本就存在乱码问题，而在 TiDB 中则可能变成了刚好能够计算的键。因此，需要提前在 Oracle 进行优化和调整。

全真模拟验证

数据模拟板块平安科技使用的组件是 openresty。迁移业务过来后，平安科技通过 openresty 进行异步处理、限流和放大倍数（中间的挡板服务可以实现灵活应用）。在执行过程中，起初刚迁移时所有 TiKV 的 CPU 使用率都达到了 100%，这是因为表中有 260G ，很多 SQL 性能很差，这种情况可以通过第二个 openresty（挡板服务）和接口放大倍数成功实现了来优化。平安科技的解决经验是例如有 100 个入口，可以先挑一个来测试，逐步增加负载（如从 0.1 倍开始）。

性能优化

性能优化是整个迁移过程中最复杂且技术含量最高的部分。根据经验，复杂业务去 O 的 SQL 改写率达到 80%，较为简单业务的 SQL 改写率为 30%，以下是平安科技在性能优化方面的方案。也建议大家使用 TiDB LTS（长期支持）高版本，TiDB 高版本的很多功能都能助力大家的性能优化，例如通过 SPM 绑定现有 SQL 的执行计划，可以极大地方便 DBA 对 SQL 的优化调整。

切换方案

在切换方案方面，我们首先要求生产环境的切换必须经过严格的数据比对和同步比对。我们在使用 Oracle 架构的触发器过程中，发现只有两个用户可以写回数据，如果没有这两个用户，都无法写入。千万别相信业务方说“这没问题”，我们之前就遇到过类似的情况。因此，平安科技内部我们要求必须通过数据验证，确保只有特定用户可以写入，而后应用关闭 Oracle 读写，全量切换到 TiDB 对用户进行验证。最后就是停应用，停掉反向的链路，去除限制业务用户写入的触发器，然后将应用的连接改为 Oracle，最后启动应用。

切换方案的一个显著优点是，如果应用出现异常，可以立即切换回 Oracle，确保系统的稳定性和数据的安全性。这种操作相对简单，属于 PV 操作。但需要注意的是，如果业务逻辑本身存在问题，即使切换回 Oracle，问题仍然会存在，因此需要在切换前进行充分的验证和测试。

注意事项：

涉及大量主机资源，需要提前申请采购
存储过程、自定义函数等oracle独有特性需要提前改造
业务性能压力测试需要全面测试，提前解决sql性能问题
切换时需要准备多台物理机，该业务凌晨切换时扩容了多台物理机

技术篇｜平安科技从 Oracle 到 TiDB 迁移

导读