背景
前段时间完成了一个重构项目的数万数据的迁移（为了提升系统性能以及业务的合理划分，从系统A中重构出系统B，数据库从SQL SERVER变为MYSQL），上线后遇到了一些问题，在此记录下来提醒自己以后的数据迁移该注意哪些方面。
问题汇总
- 迁移过程中脚本出现问题
- 迁移完成后，部分数据是错的
原因
对于第一点，这里出现问题的原因是一个是线上数据业务表的字段长度远大于新表, 导致新表数据无法新增报错或者批量新增的脚本太多执行报错。脚本在测试环境跑过，但是与线上数据相差较大，线上数据不论是数据量和单个业务表的字段长度远大于新表
第二点的一个原因业务表的字段没有理解清楚，不够透彻，比如原表有以下四个字段表示商品的长宽（举例）：a，b,historyA,historyB，迁移数据时理所当然的使用了a，b，没有去了解另外两个字段代表的意义（historyA，historyB是原始尺寸，a，b是特殊规则后的尺寸），导致线上迁移的数据只要是需要特殊服务的尺寸全是错误。另一个原因是迁移脚本漏了一个重要业务数据的标识，这一点其实可以在测试环境可以发现的，主要是由于这个重要业务能测试的账号少，加上我平常很少进行这个操作，心存侥幸觉得没问题造成了这个后果。
总结
经过这次迁移数据后，我对迁移数据有了以下几点思考
- 迁移数据要用正式环境数据进行测试，而且要多演练几次
- 迁移数据脚本编写前，迁移要多做调研，宁愿多花时间在前期的调研上，也不要等出现问题再来解决
- 新库的数据表，每一个字段都要反复核对它对应得是原表的哪个字段
- 迁移脚本每一行都要经过代码审查，这一点要求审查人员一定是特别熟悉原业务的，大家一起走查代码才能发现潜在的问题并解决
大家还有什么好的迁移数据方法，欢迎一起讨论。