3. 迁移前的现状评估：源库性能基线采集、数据量/对象/依赖关系梳理、兼容性预分析
迁移前的现状评估是整个数据库迁移工程的“体检”阶段。只有全面、准确地掌握源库的运行状态、资产规模、对象依赖以及目标平台的兼容性差异，才能制定出合理的迁移策略、资源规划与风险预案。本章围绕三个核心评估维度展开：性能基线采集、数据量与对象依赖梳理、兼容性预分析。
3.1 源库性能基线采集
性能基线是迁移后性能对比与容量规划的基准。采集应覆盖业务高峰期与低峰期，至少持续7天（建议14天），以消除偶发波动。核心采集指标如下表所示：
| 指标类别 | 关键指标 | 采集工具/方法 | 用途 |
|---|---|---|---|
| 吞吐量 | QPS、TPS、每秒事务数 | 数据库内置监控（如AWR、pg_stat_statements） | 评估目标库规格与并发能力 |
| 资源消耗 | CPU使用率、内存占用、磁盘IOPS与吞吐 | OS工具（top、iostat）+ 数据库视图 | 确定目标实例规格与存储类型 |
| 连接数 | 活跃连接数、总连接数、连接池水位 | 数据库连接统计视图 | 规划连接池大小与代理层配置 |
| 慢查询 | 慢SQL数量、最长执行时间、TOP N SQL | 慢查询日志、性能分析工具 | 识别需要预优化的SQL |
| 锁与等待 | 锁等待次数、死锁频率、平均等待时间 | 数据库锁监控视图 | 评估迁移期间并发冲突风险 |
实践建议： 对于Oracle源库，务必采集AWR（Automatic Workload Repository）报告；对于MySQL，建议开启performance_schema并采集sys.schema_auto_increment_columns等视图。所有基线数据应归档至统一的时间序列数据库，便于后续趋势分析。
3.2 数据量、对象与依赖关系梳理
在迁移前，必须对源库的“家底”进行彻底盘点。这包括数据量统计、对象清单以及对象间的依赖关系。依赖关系是迁移顺序编排的关键输入，遗漏依赖可能导致迁移失败或数据不一致。
3.2.1 数据量统计
- 总数据量： 所有用户表的数据行数、总存储空间（数据文件大小 + 索引大小）。
- 大表清单： 单表超过100GB或行数超过1亿的表，需单独评估迁移策略（如分区迁移、并行加载）。
- 增量数据速率： 每日/每小时的数据增长量，用于估算迁移窗口与同步延迟。
3.2.2 对象清单
对象类型包括但不限于：表、索引、视图、存储过程、函数、触发器、序列、同义词、物化视图、用户自定义类型、包（Package）等。建议使用自动化脚本生成对象清单，并标记每个对象的依赖方与被依赖方。
3.2.3 依赖关系梳理
依赖关系通常分为以下几类：
- 外键依赖： 父表与子表的引用关系，决定数据加载顺序。
- 视图/物化视图依赖： 视图定义中引用的基表或其他视图。
- 存储过程/函数依赖： 代码中调用的其他对象或包。
- 触发器依赖： 触发器所依附的表以及触发的操作。
- 序列依赖： 哪些表或列使用了该序列作为默认值。
依赖关系可视化： 下图展示了一个典型电商数据库的对象依赖关系拓扑，其中“订单表”作为核心节点，被多个视图、存储过程和外键所依赖。迁移时需优先迁移“用户表”和“商品表”，再迁移“订单表”，最后迁移依赖订单表的视图和存储过程。
3.3 兼容性预分析
兼容性预分析旨在识别源库与目标库（如Oracle → MySQL、MySQL → TiDB、SQL Server → PostgreSQL）之间的语法、功能、数据类型与行为差异。预分析应覆盖以下四个层面：
- 数据类型映射： 检查源库特有类型（如Oracle的NUMBER、CLOB、BLOB；SQL Server的DATETIME2、HIERARCHYID）在目标库中是否有等价类型，以及精度/长度是否一致。
- SQL语法兼容性： 分析存储过程、函数、触发器中使用的方言特性（如Oracle的MERGE INTO、CONNECT BY；MySQL的LIMIT语法差异）。
- 内置函数与操作符： 对比日期函数、字符串函数、聚合函数、窗口函数等是否存在名称或行为差异。
- 事务与隔离级别： 确认目标库是否支持源库使用的事务隔离级别（如Oracle默认的READ COMMITTED、MySQL的REPEATABLE READ），以及分布式事务（XA）的支持情况。
常见陷阱： 许多团队在兼容性分析中只关注DDL（数据定义语言）的转换，而忽略了DML（数据操作语言）和存储过程内部的隐式类型转换差异。例如，Oracle中
'' 被视为NULL，而PostgreSQL中 '' 是空字符串。此类差异必须在预分析阶段标记并制定改写规则。
3.3.1 兼容性预分析流程
建议采用“工具扫描 + 人工复核”的双轨模式：
- 工具扫描： 使用商业化或开源迁移评估工具（如AWS DMS Schema Conversion、Oracle SQL Developer Migration、pgloader、Archery）自动扫描源库对象，生成兼容性报告。
- 人工复核： 对工具标记的“高风险”或“不支持”项进行人工代码审查，必要时编写转换脚本或寻找替代方案。
- 回归测试： 在预生产环境对转换后的DDL与DML进行功能回归，确保业务逻辑正确。
3.3.2 兼容性评估矩阵示例
| 源库特性 | 目标库支持情况 | 风险等级 | 转换策略 |
|---|---|---|---|
| Oracle ROWNUM | MySQL 8.0 支持 LIMIT | 低 | 自动改写为 LIMIT 子句 |
| Oracle CONNECT BY | MySQL 不支持递归CTE | 高 | 改写为递归CTE（MySQL 8.0+）或应用层实现 |
| SQL Server SEQUENCE | PostgreSQL 原生支持 | 低 | 直接映射 |
| MySQL ENUM | TiDB 支持 | 低 | 直接迁移 |
| Oracle 物化视图（增量刷新） | PostgreSQL 物化视图（全量刷新） | 中 | 改为全量刷新或使用第三方工具实现增量 |
兼容性预分析输出物： 一份完整的兼容性评估报告，包含：所有不兼容项清单、每项的风险等级、建议的转换方案、预估的转换工作量（人天）。该报告是后续迁移实施与测试计划的核心输入。
3.4 评估阶段总结
迁移前的现状评估不是一次性的“快照”，而是一个持续迭代的过程。随着评估的深入，可能会发现新的依赖关系或兼容性问题，需要及时更新评估报告。建议在评估阶段结束时，组织一次由DBA、应用开发、架构师共同参与的评审会，确认评估结果完整、准确，并据此调整迁移方案与资源计划。