Oracle 核心库的迁移，最怕的不是迁移过程出问题，而是迁移后线上跑着跑着出了性能问题。特别是峰值交易和夜间批处理这两个极端场景，必须在迁移前充分验证。
需要验证什么？
峰值交易场景
这是最直接的压力测试目标。需要模拟的内容包括：
- 并发连接数： 生产环境的峰值连接数是多少？目标数据库的连接模型是否支持？
- TPS/QPS： 峰值时段的每秒事务数和查询数
- 混合读写比例： 读写比例是多少？长事务和短事务的分布如何？
- 热点数据： 是否存在明显的数据热点？不同产品对热点的处理能力不同
夜间批处理场景
批处理和在线交易的特征完全不同：
- 大批量操作： 批处理通常涉及大量数据的 INSERT/UPDATE/DELETE
- 长事务： 单个批处理任务可能运行数十分钟甚至数小时
- 资源独占： 批处理期间可能占用大量 CPU 和 I/O，影响在线业务
不同数据库对大事务和长事务的支持程度差异较大，部分产品对单事务的数据量或持锁时间有限制，需要在 POC 中验证。
怎么做验证？
第一步：建立性能基线
在 Oracle 上采集峰值时段和批处理时段的性能指标：
- 核心接口的 P99 延迟
- 端到端的吞吐量
- 资源使用率（CPU、内存、磁盘 I/O）
这些基线数据是后续对比的依据。
第二步：搭建压测环境
压测环境不需要和生产环境等规模，但数据分布和查询模式要尽量接近。至少需要：
- 按比例缩放的数据量
- 真实的业务查询（不是简单的主键查询）
- 模拟的并发模式
第三步：分场景压测
- 先验证单接口在目标数据库上的性能
- 再验证混合负载下的整体表现
- 最后验证批处理场景
第四步：对比分析
把压测结果和 Oracle 基线做对比，重点关注：
- P99 延迟是否在可接受范围内
- 是否有明显的慢查询
- 资源使用率是否合理
TiDB 在稳定性验证中的对应能力
TiDB 兼容 MySQL 协议，可以使用 sysbench、TPC-C 等标准压测工具建立初始性能基线。对于批处理场景，TiDB 的大事务支持可以通过参数调整来适配。TiDB Dashboard 提供了 SQL 审计和慢查询分析功能，便于定位性能问题。建议在 POC 阶段用业务实际的数据量和查询模式做一轮完整压测，重点关注批处理场景下的事务行为和资源使用。
如果你正在规划 Oracle 核心库的迁移，建议先把峰值交易和批处理两个场景的性能基线建立起来，再在目标数据库上做一轮对比验证。