别急。NineData 站在你的视角，把整个迁移过程拆解成五个可执行的关键步骤，每一步该做什么、会遇到什么问题、怎么解决，一次性讲清楚。

第一步：摸底 —— 我的数据库到底有多少 “坑”？

任何迁移的第一步，都不是直接动手，而是全面摸底。

你需要搞清楚三件事：

• 数据库对象：有多少表、视图、索引、存储过程、函数、触发器、同义词？
• 业务 SQL：应用里跑的那些 SQL 语句，哪些是 Oracle/MySQL 特有的语法？
• 风险点：这些对象与 SQL 到了 PostgreSQL 环境里，哪些能用、哪些要改、哪些彻底没法用？

如果靠人工排查，不仅效率极低，还极易遗漏关键对象，埋下上线故障隐患。

使用 NineData 迁移评估，只需配置好源数据库与目标数据库，勾选 数据库对象评估和 SQL 文本评估，系统即可自动完成全量风险识别。

SQL 支持两种采集方式：

1. 自动采集：从源数据库中采集真实业务 SQL；
2. 手动上传：支持上传本地 SQL/TXT/ZIP 格式文件，最大支持 5GB；

系统会自动输出完整的兼容性分析结果，明确告知所有对象、SQL 的兼容状态。

产出： 完整的迁移评估报告，包含风险等级、兼容性评分、所有不兼容项明细。你可以凭借这份报告，精准评估迁移范围与难度。

第二步：量化 —— 这活儿到底要干多久、花多大代价？

摸底之后，你需要用数据回答最实际的问题：改造工作量、迁移风险等级。

NineData 迁移评估会自动生成 两大核心量化指标：

• 风险等级：高 / 中 / 低，基于不兼容项数量与严重程度自动计算，直观体现迁移难度
• 兼容性评分：综合数据库对象 + SQL 文本评估得出的百分比评分，精准反映整体兼容情况

量化结果可直接用于项目规划、资源排期、向上汇报，让迁移决策不再依赖经验判断，而是有据可依。

第三步：改造 —— 不兼容的代码，到底怎么改？

这是迁移过程中最耗时的环节，也是 NineData 迁移评估的核心价值场景。

传统方式需要手动查阅语法差异、编写兼容代码，效率低、易出错。使用 NineData，系统会 自动提供改造方案：

• 对不兼容的数据库对象：展示原始 DDL + 不兼容原因 +  可直接执行的兼容 DDL
• 对不兼容的 SQL 语句：展示原始 SQL + 不兼容点 +  可直接执行的兼容 SQL

开发人员无需从零研究语法差异，直接参考系统生成的兼容代码即可完成改造，大幅提升效率、降低出错率。

第四步：验证 —— 改完之后，怎么保证上线不出事？

代码改造完成后，静态分析无法发现执行时的隐藏问题，必须进行真实验证。

NineData 提供 SQL 流量回放功能，相当于迁移前的 全真演练：

1. 在评估任务中进入「回放详情」
2. 配置目标 PostgreSQL 库，启动流量回放
3. 系统将真实业务 SQL 在目标库中实际执行

自动生成验证结果：

• SQL 回放成功率
• 执行失败 SQL 列表及详细报错信息
• 慢 SQL 识别（提前发现性能风险）

所有运行时问题提前暴露、提前修复，彻底规避上线风险。

第五步：收尾 —— 沉淀成果，让迁移可追溯、可审计

迁移完成后，需将全过程成果归档，满足团队协作、方案评审、合规审计需求。

NineData 支持 一键下载评估报告 + 流量回放报告，报告包含：

• 源 / 目标数据库信息
• 风险等级与兼容性评分
• 不兼容项清单与改造方案
• 流量回放执行结果

迁移评估报告

SQL回放报告：

报告可长期归档，实现迁移过程可追溯、可管理、可验收。

总结：平滑迁移 PostgreSQL，就这五步

从 Oracle/MySQL 迁移到 PostgreSQL，是一套标准化、可落地的工程化流程：

这套流程走下来，异构数据库迁移不再是 “盲赌式冒险”，而是 风险可见、工作量可算、方案可执行、结果可验证的确定性工程。

下次面对迁移需求，你可以胸有成竹：先用评估报告明确工作量与风险，再制定计划，确保平稳上线、零事故。

这，就是专业 DBA 的底气。