数据库迁移复杂吗？
XX DB-》MySQL
经常会被“领导”问到从某某数据库迁到MySQL复杂吗？大概需要多长时间能迁完？听到这个问题你会怎么想？你会怎么回答这个问题？想听听我的答案吗？请往下看。
通常我的回答是：“不知道，这主要取决于应用程序对数据库的依赖程度，应用程序的重要程度，以及施工单位的实施方法”。请注意，我用到了“施工单位”这个词，是不是感觉到了建筑工地。为什么我要这么说呢？通常能问出这个问题的“领导”基本上可以判断为没有IT行业实际经验的人，很有可能是采购部门出身，对于我上面的回答可能无法理解，我会接着再给他举个例子。例子通常是这样的：数据库厂商实际上就是装修材料市场的建材商，我们就是其中的一种主材，对于一种主材，会有不同的品牌，每个品牌的产品都会有着自己不同的特点，但本质上还是属于一类东西。系统集成商相当于装修公司，他们会按照设计方案选用不同的主材，将其整合在一起。也就是说，装修公司是施工单位，他们决定工期和实施方案。因此，数据库迁移这件事情得去问你的装修公司，也就是实际负责项目实施的团队。当用这个例子解释完以后，基本上领导就会能够理解迁移成本的点在哪里了。
虽然数据库迁移这种事情大部分是由“装修公司”来实施的，但也不排除有打算自己动手操作的。恰巧我的上一份工作主要做的就是数据迁移，这方面的经验还是有一些的，在这里给大家分享一下。
基本上数据库迁移的工作可以分为三部分，前期调研，中期实施，后期验证。根据项目规模的大小，各个阶段的时间略有调整，但总体来说还是三个阶段。个人认为最重要的是前期调研和后期验证阶段，之前在这两个阶段踩过无数个坑，最终导致项目无法按时交付。（我参加过的项目没有一个是按时、保质、保量完成的，因此，对于怎么样把一个项目做砸，我有着丰富的经验?）
- 前期调研阶段，这个阶段至少需要一个人对两种数据库有一定程度的了解，需要找出两种数据库的不同点有哪些？例如，字段类型，函数，存储过程，隔离级别等等一系列的区别，需要列出一个对比表格供后期使用。接下来需要调研有多少应用程序使用了这个数据库，这是一个很神奇的阶段，经常会发现有莫名其妙的连接连上这个数据库，因此需要仔细找出究竟有哪些应用程序连接到了这个库。找到之后就需要梳理在每个应用程序中使用了哪些字段类型，哪些函数、存储过程、触发器等等，然后就需要对照上面的一览表总结出需要更改的部分和相关的代码量。根据代码量，大致就可以估算出实施工期。
- 中期实施阶段，这一阶段没有什么特殊的地方，按照正常的开发实施标准，保质保量地进行施工，就能够符合项目要求。个人建议这个阶段的进度能提前尽量提前完成，省下的时间留着下一个阶段“填坑”。
- 后期验证阶段，这一阶段非常重要，是否成功交付全在这个阶段进行验证。除了标准的单元测试，结合测试和系统测试。迁移项目还需要增加一个对比测试。根据项目的重要程度，有可能采用双系统并行的策略，既新旧两个系统同步运行，每天进行数据并行校验，直至应用程序完整的遍历周期结束。最终确认系统没有问题再进行切换。需要注意的是在这个阶段很有可能出现调研阶段没有覆盖的问题，难免踩坑，因此要为这一阶段的工作量提前做好规划和准备。
关于数据库迁移的经验已经分享给大家，如果需要从其他数据库迁移至MySQL，可以使用官方的MySQL Workbench迁移向导。关于MySQL Workbench的使用和介绍请参照MySQL的图形化工具——MySQL Workbench
感谢您关注“MySQL解决方案工程师”！