Mss2sql 由于是很有针对性的从 SQLServer 迁移到 MySQL，因为界面使用了操作向导设计，使用非常容易。同时在设置的过程中，有非常多的选项进行细节调整，可以感觉到软件经过了相当长一段时间的使用渐渐完善出来的。

４、DB2DB

      DB2DB 由于是由国人开发，因此无论是界面还是提示信息，都是全程汉字。另外，由于 DB2DB 在功能上很有针对性，因为界面设计一目了然和易使用。和 mss2sql 一样， DB2DB 提供了非常多的选项供用户进行选择和设置。

三、处理速度和内存占用评测

      在本评测前，本人的一位资深同事曾经从网上下载了某款迁移软件，把一个大约2500万记录数的数据表转送到阿里云 MySQL，结果经过了三天三夜（好在其中两天是星期六和星期日两个休息日）都未能迁移过来。因此这一次需要对这四个工具的处理速度作一个详细的测试。

      考虑到从 SQL Server 迁移到 MySQL 会出现两种不同的场景：

● 从 SQL Server 迁移到本地 MySQL 进行代码测试和修改；
● 从 SQL Server 迁移到云端 MySQL 数据库正式上线使用；

      因此我们的测试也会针对这两个场景分别进行评测，测试结果如下（记录数约为 328万）：

工具名称 迁移到本地耗时 迁移到云端耗时 最高CPU占用 内存占用

SQLyog 2806秒 4438秒 08% 20MB

Navicat Premium 598秒 3166秒 52% 32MB

Mss2sql 726秒 1915秒 30% 12MB

DB2DB 164秒 1282秒 34% 40MB

注：红色字体标识为胜出者。

以下为测试过程中的截图：

１、SQLyog

２、Navicat Premium

注意：我们在测试 Navicat Premium 迁移到  MySQL 时发现，对于 SQL Server 的 Money 类型支持不好（不排除还有其它的数据类型支持不好）。Money 类型字段默认的小数位长度为 255，使得无法创建数据表导致整个测试无法成功，需要我们逐张表进行表结构修改才能完成测试过程。

      Navicat Premium 的处理速度属于中等，不算快也不算慢，但 CPU 占用还有内存占用都处于高位水平。不过以现在的电脑硬件水平来说，还是可以接受。但 CPU 占用率太高，将使得数据在导入的过程中，服务器不能用于其它用途。

３、Mss2sql

Mss2sql 并没有提供计时器，因此我们使用人工计时的方法，整个过程处理完毕大于是 726 秒。Mss2sql 的 CPU 占用率相对其它工具来说较高，但仍属于可以接受的范围之内。

４、DB2DB

DB2DB 同样迁移 300万数据时，仅仅使用了 2 分 44 秒，这个速度相当惊人。不过最后的结果出现一个 BUG，就是提示了转换成功，但后面的进度条却没有走完（在后面的数据完整性评测中，我们验证了数据其实是已经全部处理完毕了）。

四、数据完整性评测

      把数据准确无误地从 SQL Server 迁移到 MySQL 应该作为这些工具的一个基本要求，因此这里我们对四种工具转换之后的结果进行检查。