关于数据迁移的记录

背景

  前段时间完成了一个重构项目的数万数据的迁移（为了提高系统性能以及业务的合理划分，从系统A中重构出系统B，数据库从SQL SERVER变为MYSQL），上线后遇到了一些问题，在此记录下来提醒本身之后的数据迁移该注意哪些方面。

问题汇总

1. 迁移过程当中脚本出现问题
2. 迁移完成后，部分数据是错的

缘由

  对于第一点，这里出现问题的缘由是一个是线上数据业务表的字段长度远大于新表, 致使新表数据没法新增报错或者批量新增的脚本太多执行报错。脚本在测试环境跑过，可是与线上数据相差较大，线上数据不管是数据量和单个业务表的字段长度远大于新表
  第二点的一个缘由业务表的字段没有理解清楚，不够透彻，好比原表有如下四个字段表示商品的长宽（举例）：a，b,historyA,historyB，迁移数据时理所固然的使用了a，b，没有去了解另外两个字段表明的意义（historyA，historyB是原始尺寸，a，b是特殊规则后的尺寸），致使线上迁移的数据只要是须要特殊服务的尺寸全是错误。另外一个缘由是迁移脚本漏了一个重要业务数据的标识，这一点其实能够在测试环境能够发现的，主要是因为这个重要业务能测试的帐号少，加上我日常不多进行这个操做，心存侥幸以为没问题形成了这个后果。

总结

  通过此次迁移数据后，我对迁移数据有了如下几点思考

1. 迁移数据要用正式环境数据进行测试，并且要多演练几回
2. 迁移数据脚本编写前，迁移要多作调研，宁愿多花时间在前期的调研上，也不要等出现问题再来解决
3. 新库的数据表，每个字段都要反复核对它对应得是原表的哪一个字段
4. 迁移脚本每一行都要通过代码审查，这一点要求审查人员必定是特别熟悉原业务的，你们一块儿走查代码才能发现潜在的问题并解决

你们还有什么好的迁移数据方法，欢迎一块儿讨论。