迁移数据库这活儿，最贵的成本往往不在搬数据的那几个小时，而在搬完才发现表名全变小写、存储过程一调就报错，然后灰头土脸回滚。达梦启云数据库这类国产库往上走，流程和 MySQL 那一套习惯差得挺远，动手前有三件事必须先摸清，不摸清就等于自己给自己挖坑。
达梦启云数据库的迁移，先卡在兼容模式上
达梦有面向 Oracle 的兼容写法，也有偏 MySQL 的写法，不同版本、不同实例初始化时选的模式可能不一样。你本地开发库是照 Oracle 的习惯写的，目标实例按默认参数开出来，空值拼接、隐式类型转换、日期格式化这些行为就可能对不上。别指望迁移工具一键翻译，先把用到存储过程、触发器、自定义函数的清单拉出来，逐个在目标环境里跑一遍。跑不通的趁早改，别等几百万行数据都导完了才回头动代码。
这块最怕听二手经验。「我朋友说这样能跑」不算数，兼容性细节以达梦官方文档或者服务商给的版本说明为准，版本号差一点点，行为就可能不一样。
字符集和大小写敏感，建实例那一下就定死了
这条被忽略的概率最高。建库、建实例时的大小写敏感、字符集这些参数，事后基本改不了，只能推倒重建。老系统里表名、字段名大小写混着写，SQL 里又不加引号，迁到一个大小写敏感的实例上，语句直接找不到对象，报错还挺隐蔽。字符集两边不一致，中文、特殊符号、生僻字在传输过程中变问号或者乱码，等你发现的时候数据已经躺在里面了。
所以第一步不是打开迁移工具，是把源库的初始化参数导出来，和目标实例的参数一条一条对齐。对不上的，先决定是改源端还是干脆重开一个实例，这个决定越早做越省事。
数据量从来不是问题，迁移窗口才是
总有人上来就问几百个 G 能不能迁。能迁，问题是你打算停多久。全量导一遍的时间还估得出来，难估的是校验和失败重试这两笔暗账。比较稳的做法是把窗口切成两段：全量加增量同步先跑上一阵子追平，最后只留一个很短的切换窗口。全量那一次别直接压在生产库上跑，找个备库或者快照读，不然业务白天就开始卡。
窗口定下来之后往上加三成缓冲，这是我踩过坑之后的习惯。真到了那天，慢的往往不是数据库，是你没想到的那个环节。
一致性校验，回答「到底迁干净没有」
行数对上了不等于数据对。主键数量一致，但某个字段被截断、小数位精度丢了、时间类型的时区错位，这些行数校验根本看不见。至少做三层：表行数、关键字段的汇总值（金额合计、最大最小 ID 之类）、抽样逐字段比对。用脚本比，不要靠人眼看，人眼比几千行就会开始骗自己。
校验脚本本身也要在预演里跑通。我见过脚本逻辑没问题、但没在预演环境跑过，正式切换那天第一次执行就报权限错误，硬生生多停了半个多小时。这种事一次就够记一辈子。
达梦启云数据库上的连接数和授权，小地方最容易翻车
应用侧连接池的上限，和目标实例允许的最大连接数，这两个数字不对等，切换当晚就会一片连不上。还有账号授权：迁移账号得有建表、建索引、建序列的权限，只给一个读写权限，导到一半就卡住，你还得停下来找 DBA 加权限。防火墙策略、白名单 IP 也要提前放通，别等切完了才发现应用服务器压根连不上新实例。
这类琐碎项最好是列成清单逐条打勾，一条一条划掉，别凭记忆。记忆在切换那天特别不靠谱。
回滚方案得是能真的按下去的东西
回滚不是一句「不行就切回去」这么轻松。切回去意味着切换之后写进新库的那部分数据要能反向同步回老库，或者你得接受那一段数据直接丢掉。切之前老库是置只读还是双写，得提前定死。回滚脚本要演练，演练的时候把耗时记下来，因为真正需要回滚的时候，没人有耐心现场研究脚本怎么写。
这一步做不扎实，切换当天所有人都不敢按那个按钮，最后拖到半夜，越拖越容易出错。回滚方案应该当成一个交付物来验收，不是一句安慰人的话。
动手之前，把这几样摆在一张纸上：源库和目标实例的初始化参数对比、存储过程和触发器的执行结果、全量与增量的时间估算、三层校验脚本、账号和连接数清单、回滚步骤加演练记录。哪一项还空着，就先别去定切换时间。真出事的那天，救你的不是迁移工具有多智能，而是你提前留好的那条退路还在。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
