Navicat数据迁移怎么操作 Navicat数据迁移后表结构不一致怎么办

Navicat数据迁移的操作，和迁移之后表结构不一致的处理，关键并不在于把源库和目标库连接起来就直接开始传输，而是需要先确认好迁移的对象、表结构、字段的映射、索引和约束，还有目标库的类型。Navicat提供了Data Transfer、Data Synchronization和Structure Synchronization这些功能，可以用来处理数据库对象、表数据，还有结构差异这类问题。

一、Navicat数据迁移怎么操作

在进行数据迁移以前，需要先判断这是同类型数据库之间的迁移，还是跨类型数据库的迁移。比如从MySQL迁移到MySQL，关注的重点大多在表、索引、字符集和数据量上面；要是从SQL Server迁移到MySQL，那字段类型、默认值、自增规则和函数语法这些，就需要提前去核对。

1、把源库和目标库确认好

在开始迁移之前，要先去测试两个连接是不是都正常，确认一下账号有没有读取源库、在目标库创建表、写入数据、建立索引，还有执行约束的权限。不要只拿管理员的账号测试过一次，就开始动手迁移，正式迁移的时候，最好是使用专门给这个项目准备的账号，这样可以避免权限过大，或者是不小心连错了环境。

2、进到数据传输的功能里面去

依次打开【Tools】菜单，再找到【Data Transfer】，然后分别把Source和Target这两个连接选好。

在Source里面，去选择需要迁移的数据库或者Schema，在Target里面，则去选择目标的数据库。要是只想把结构备份下来，那也可以把目标设置成文件，并且导出SQL的脚本。Navicat的数据传输向导，它支持去选择连接、对象和传输的模式，在正式开始以前，还会让用户再去确认一遍配置。

3、把需要迁移的对象选出来

去勾选那些需要迁移的表、视图、函数、过程，或者是其他的对象。在这个地方，不要盲目地去全选，特别是从生产库往测试库迁移的时候，要去确认一下，这里面是不是包含了日志表、临时表、历史表，还有那种大字段的表。对象太多了，是会把迁移的时间给拉长的，同时也会增加失败以后，回滚和核对的难度。

4、把传输的选项检查一下

在迁移数据的时候，要去确认好要不要创建表、要不要创建记录、是覆盖掉目标表，还是直接在后面追加数据。要是目标库里面已经存在同名的表了，那就需要特别留意，到底是清空以后再导入，还是直接追加进去。Navicat它支持用户自己去定义要传输哪些字段，以及字段之间怎么去映射，碰上字段名不一样，或者目标表已经有了一套结构的时候，这一步就会显得很重要。

二、Navicat数据迁移后表结构不一致怎么办

表结构出现了不一致，不能只是去看表的名字和字段的个数。真正会对业务运行造成影响的，往往是字段的类型、长度、字符集、默认值、索引、主键、外键、自增的规则，还有注释这一些细节。

1、先去对比字段的定义

先去看一看字段的名字、数据的类型、长度、小数的位数、是不是允许为空，还有默认值。在跨库迁移的时候，字段的类型是有可能被自动转换的，比如说文本、日期、布尔、枚举、大字段这些类型，在不同的数据库里面，它们的表现并不是完全一样的。字段看上去是能够存数据的，但这并不代表业务的查询和写入，就都是正常的。

2、再去检查索引和约束

当表结构不一致的时候，要重点去看主键、唯一索引、普通索引、外键，还有自增的字段。有很多迁移的问题，并不是数据没有传过去，而是索引或者约束没有被同步过去，结果就导致查询变慢了、重复的数据被写了进去，或者应用在做写入操作的时候，直接报了错。在做结构核对的时候，不要只是把表设计那个页面打开看一看，还要去翻看索引和约束的页面。

3、借助结构同步的功能，来辅助核对

可以借助【Structure Synchronization】这个功能，去比较源库和目标库之间，结构上的差异。

结构同步这个功能，比较适合在迁移完成了以后，去检查表、字段、索引，还有对象定义上面的差别。发现了差异以后，不要立刻就全部执行同步的脚本，而是应该先去逐项确认一下，哪些差异是因为迁移本身造成的，哪些差异是目标库这边，本来就根据环境需要，特意保留下来的。

三、迁移后怎么做验证和收尾

数据迁移完成了，并不代表这项工作就结束了。真正牢靠的迁移，是得要能够证明表的结构是正确的、数据的数量是对的、关键的业务是能够跑通的，而且后面还要有记录，可以用来追溯。

1、把数据的数量核对一下

在迁移完成了以后，先去对比一下源表和目标表的记录条数，然后再去抽查一下那些关键表里面的数据内容。对于那些订单、用户、财务、库存这一类的核心表，最好是按照主键的范围、日期的范围，或者是业务的状态，去做抽样的核对，仅仅看一下总的行数，那还是不够的。

2、去测试一下关键的查询

表结构不一致，有的时候并不会马上就报错，但是它可能会影响到查询的性能，或者是业务的逻辑。在迁移完成了以后，要去跑一下那些常用的查询、报表的SQL、写入的流程，还有更新的流程，去观察一下，有没有出现字段被截断、字符变成乱码、日期不正常、精度丢失，或者是索引没有被用上这类问题。

3、把迁移的记录保留下来

最好是去记录一下迁移的时间、源库和目标库各自是什么、Navicat的版本、迁移了哪些对象、传输的选项、异常是怎么处理的，还有最终核对的结果。这样，后面要是发现了数据上的差异，就可以很快地回到迁移的那个过程里面去定位，而不是只靠着个人的回忆。

总结

Navicat数据迁移应该怎么操作，以及迁移之后表结构不一致又该怎么处理，可以按照“先确认好连接和权限，再用Data Transfer选好对象和选项，迁移完了以后，用结构同步和数据核对，去检查存在的差异”这样的思路来办。当表结构不一致的时候，不要只是去数字段的个数，而是要重点去核对字段的类型、默认值、索引、约束、自增的规则，还有字符集。把迁移的记录、结构的对比，还有业务的验证，这几件事情都做好了以后，Navicat的数据迁移才会更加稳当，后面再去排查问题，也会更加方便。