女的男的做那个视频网站,网站规划设计的一般流程,h5app开发框架,wordpress 3.9.2 漏洞我之所以会写这篇对比文章#xff0c;是因为公司新产品研发真实经历过这个痛苦过程#xff08;传统基于 SQL Server开发的C/S 产品转为 MySQL云产品#xff09;。首次需要数据转换是测试环节#xff0c;当时为了快速验证新研发云产品性能与结果准确性#xff08;算法类是因为公司新产品研发真实经历过这个痛苦过程传统基于 SQL Server开发的C/S 产品转为 MySQL云产品。首次需要数据转换是测试环节当时为了快速验证新研发云产品性能与结果准确性算法类所以需大量的原始数据最快的办法就是使用老产品的真实数据。因为在前期数据转换时主用于内部验证并没有花很多心思去处理这个事情一般数据能导过去不对的地方自己再手工处理一下就好了。后面对这个转换工具引起了极大的重视是正式有老客户升级时因为正式投入使用就容不得半点错误当时至少有几百家客户需要升级新产品所以数据转移第一要求是百分百的准确率其次是速度要快。现在回想起来当时要有这么一篇对比文章那我就不会浪费那么多时间在查找、对比、验证工具和数据维护修正上了所以真心希望通过这篇对比文章能给大家提供一些参考或帮助下面进入正题
在部署前期首要任务就是考虑如何快速把基于 SQL Server 数据库的应用程序移植到阿里云的 MySQL 数据库。由于程序是基于 O/R mapping 编写并且数据库中没有使用存储过程、用户函数等数据库功能因此仅仅需要考虑的是数据库中的数据如何转换到新的 MySQL 数据库中。
通过度娘查找找到如下四种可以使用的工具并且每一种工具都有大量的用户还有不少用户在自已的博客中写下了图文使用经验这四种工具分别是
● SQLyoghttps://www.webyog.com/product/sqlyog ● Navicat Premiumhttps://www.navicat.com/products/navicat-premium ● Mss2sqlhttp://www.convert-in.com/ ● DB2DBhttp://www.szmesoft.com/DB2DB
由于公司需要处理的是业务数据库因此必须保证数据转换的准确率不允许丢失数据数据库字段、索引完整并且需要保证数据库迁移后能立即使用。因此在实施数据迁移前对这几种 SQLServer 到 MySQL 的迁移工具进行一个全面测试。下面我们将基于以下需求为前提进行测试
● 软件易用性 ● 处理速度和内存占用 ● 数据完整性 ● 试用版限制 ● 其它功能
一、测试用的源数据库和系统
用于测试的源数据库名为 MesoftReportCenter。由于其中一个测试工具试用版限制只能处理两张数据表的原因因此我们只选取了记录数最多的两张数据表HISOPChargeIntermediateResult 和 HISOPChargeItemIntermediateResult。两张数据表合计的记录数约为 328万数据库不算大但针对本次进行测试也基本上足够了。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OgH2YqjM-1675732559512)(https://www.liangtengyu.com:9998/images/pic_c2c20e19.png)]
SQLServer 服务器和 MySQL 服务器分别运行在两台独立的虚拟机系统中而所有的待测试程序都运行在 MySQL 所在的服务器上面。其中
SQLServer 服务配置
● 操作系统Windows XP ● 内 存2GB ● 100MB 电信光纤
MySQL 服务配置
● 操作系统Windows XP ● 内 存1GB ● 100MB 电信光纤
同时为了测试的公平性除 Mss2SQL 外所有软件都是直接从官网下载最新的版本。 Mss2SQL 由于试用版的限制原因没有参与测试而使用了网上唯一能找到的 5.3 破解版进行测试。
二、软件易用性评测
软件易用性主要是指软件在导入前的配置是否容易。由于很多软件设计是面向程序员而非一般的数据库管理人员、甚至是普通的应用程序实施人员而这一类人员很多时候并没有数据源配置经验。因为一些使用 ODBC 或者 ADO 进行配置的程序往往会让这类用户造成困扰主要是不知道应该选择什么类型的数据库驱动程序。下面让我们看看四个工具的设计界面
、SQLyog
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jN79ZizE-1675732559513)(https://www.liangtengyu.com:9998/images/pic_d5d6e8c6.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yJbB36ev-1675732559513)(https://www.liangtengyu.com:9998/images/pic_43ae2941.png)]
SQLyog 使用的是古老的 ODBC 连接但对于新一代的程序来说这种方式的非常的不熟悉并且不容易使用并且必须要求本机安装好相应的数据库的 ODBC 驱动程序SQL Server 一般自带好。
、Navicat Premium
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zp6iMIC5-1675732559513)(https://www.liangtengyu.com:9998/images/pic_dafdfec2.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jN35t6IY-1675732559513)(https://www.liangtengyu.com:9998/images/pic_ff23c034.png)]
Navicat Premium 是四个应用工具中设计最不人性化的一个从上图怎么也想像不到要点按那个小按钮来添加一个新的连接并且这个连接设置不会保存每次导入时都必须重新设置。 Navicat Premium 使用的是比 ODBC 稍先进的 ADO 设置方式199X年代的产物但使用上依然是针对老一代的程序员。
、Mss2sql
Mss2sql 是最容易在百度上搜索出来的工具原因之一是它出现的时间较早。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6rPp1005-1675732559513)(https://www.liangtengyu.com:9998/images/pic_61f66857.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zLbO0B7z-1675732559513)(https://www.liangtengyu.com:9998/images/pic_dc8b9c8a.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-csXNDShq-1675732559513)(https://www.liangtengyu.com:9998/images/pic_7259cb64.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-deDeqOt0-1675732559514)(https://www.liangtengyu.com:9998/images/pic_02fd3985.png)]
Mss2sql 由于是很有针对性的从 SQLServer 迁移到 MySQL因为界面使用了操作向导设计使用非常容易。同时在设置的过程中有非常多的选项进行细节调整可以感觉到软件经过了相当长一段时间的使用渐渐完善出来的。
、DB2DB
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AKNuInSx-1675732559514)(https://www.liangtengyu.com:9998/images/pic_c0d41b84.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OmZaZXe1-1675732559514)(https://www.liangtengyu.com:9998/images/pic_0ce1054c.png)]
DB2DB 由于是由国人开发因此无论是界面还是提示信息都是全程汉字。另外由于 DB2DB 在功能上很有针对性因为界面设计一目了然和易使用。和 mss2sql 一样 DB2DB 提供了非常多的选项供用户进行选择和设置。
三、处理速度和内存占用评测
在本评测前本人的一位资深同事曾经从网上下载了某款迁移软件把一个大约2500万记录数的数据表转送到阿里云 MySQL结果经过了三天三夜好在其中两天是星期六和星期日两个休息日都未能迁移过来。因此这一次需要对这四个工具的处理速度作一个详细的测试。
考虑到从 SQL Server 迁移到 MySQL 会出现两种不同的场景
● 从 SQL Server 迁移到本地 MySQL 进行代码测试和修改 ● 从 SQL Server 迁移到云端 MySQL 数据库正式上线使用
因此我们的测试也会针对这两个场景分别进行评测测试结果如下记录数约为 328万
工具名称迁移到本地耗时迁移到云端耗时最高CPU占用内存占用SQLyog2806秒4438秒08%20MBNavicat Premium598秒3166秒52%32MBMss2sql726秒1915秒30%12MBDB2DB164秒1282秒34%40MB
注红色字体标识为胜出者。
以下为测试过程中的截图
、SQLyog
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OIoRDWS5-1675732559514)(https://www.liangtengyu.com:9998/images/pic_ed4fe8b8.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v02wtACK-1675732559514)(https://www.liangtengyu.com:9998/images/pic_9bd30914.png)]
、Navicat Premium
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nisxjd23-1675732559514)(https://www.liangtengyu.com:9998/images/pic_9edf32f2.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SRXLhzZs-1675732559515)(https://www.liangtengyu.com:9998/images/pic_bbdd0f13.png)]
注意 我们在测试 Navicat Premium 迁移到 MySQL 时发现对于 SQL Server 的 Money 类型支持不好不排除还有其它的数据类型支持不好。Money 类型字段默认的小数位长度为 255使得无法创建数据表导致整个测试无法成功需要我们逐张表进行表结构修改才能完成测试过程。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PCyQ7Gbu-1675732559515)(https://www.liangtengyu.com:9998/images/pic_88e7101f.png)]
Navicat Premium 的处理速度属于中等不算快也不算慢但 CPU 占用还有内存占用都处于高位水平。不过以现在的电脑硬件水平来说还是可以接受。但 CPU 占用率太高将使得数据在导入的过程中服务器不能用于其它用途。
、Mss2sql
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Yo1W4rnU-1675732559515)(https://www.liangtengyu.com:9998/images/pic_d5e08164.png)]
Mss2sql 并没有提供计时器因此我们使用人工计时的方法整个过程处理完毕大于是 726 秒。Mss2sql 的 CPU 占用率相对其它工具来说较高但仍属于可以接受的范围之内。
、DB2DB
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9GJ84Q7D-1675732559515)(https://www.liangtengyu.com:9998/images/pic_d5a91a47.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m2iZCHd7-1675732559515)(https://www.liangtengyu.com:9998/images/pic_d78c87f6.png)]
DB2DB 同样迁移 300万数据时仅仅使用了 2 分 44 秒这个速度相当惊人。不过最后的结果出现一个 BUG就是提示了转换成功但后面的进度条却没有走完在后面的数据完整性评测中我们验证了数据其实是已经全部处理完毕了。
四、数据完整性评测
把数据准确无误地从 SQL Server 迁移到 MySQL 应该作为这些工具的一个基本要求因此这里我们对四种工具转换之后的结果进行检查。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rxlSOHQW-1675732559515)(https://www.liangtengyu.com:9998/images/pic_8155c93c.png)]
我们通过后台 SQL 对记录数进行检查发现所有的工具都能把记录完整地迁移到新的数据库。如果仔细观察可以发现上图中各个数据库的大小是不一致的基本的判断是由于各种工具在映射数据表字段时字段长度取值可能不能而引起的。而 mesoftreportcenter2 数据库大小比起其它数据库差不多少了一半这引起了我们的注意。通过分析 我们发现 Navicat Premium 在迁移数据库时并不会为该数据库所有数据表创建索引和主键缺少索引和主键的数据库大小显然比其它数据库要少得多。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tzOVC6Br-1675732559515)(https://www.liangtengyu.com:9998/images/pic_5896a276.png)]
为了解各工具迁移后的数据库能否立即应用于生产环境我们对创建后的数据表进行了更深入的分析发现各工具对字段默认值的支持程度也不尽相同。其中
● SQLyog完整支持 SQL Server 的默认值 ● Navicat Premium完全不支持默认值所有迁移后的数据表都没有默认值 ● Mss2sql支持默认值但有严重错误 ● DB2DB完整支持 SQL Server 的默认值。
Mss2sql 的默认值有一个严重的错误在 SQL Server 中字段默认值为空字符串 ‘’但迁移之后变成两个 ‘’ 符号。 Mss2sql 这个严重的错误会使得程序在正式环境运行后数据库会产生错误的数据
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-coK5le7P-1675732559515)(https://www.liangtengyu.com:9998/images/pic_7a468f4d.png)]
在一些老旧的系统中数据库还会存在 Text、二进制类型的字段数据通过测试对比后四种工具都完美支持 Text 和 二进制Image类型字段。
小结
测试项目SQLyogNavicat PremiumMss2sqlDB2DB表结构支持支持支持支持字段长度支持部分支持对Money等支持不好支持支持数据完整完整完整完整索引支持不支持支持支持关键字支持不支持支持支持默认值支持不支持支持但有严重错误支持二进制数据支持支持支持支持
五、各工具其它功能及试用版限制
估计由于数据库同步会存在一些技术难题的原因4 款工具目前都是只是提供试用版本最后我们来看看四个工具的试用版本各自的限制是什么
工具名价格试用限制其它功能备注SQyog$19930天试用并且只允许转换两张数据表无 Navicat Premium$799 无 Mss2sql$49每张数据表只允许有50秒处理时间支持导出为 SQL DB2DB19910万记录限制支持导出为 SQL
四种工具中由于 SQLyog 和 Navicat Premium 提供了额外的管理功能所以价格相比其它两款工具的要高得多。特别是 Navicat必须是 Premium 版本才提供数据转换的功能。而 Mss2sql 最新版本的试用版只提供了 50 秒处理时间因为实用价值不大。而笔者与 DB2DB 作者联系时得知DB2DB 设置 10万记录限制主要是考虑国内很多小型软件记录数都是少于 10 万笔而这一类人群一般都是小型创业团队。
六、评测总结
最后对四款软件的测试结果作一个整体的总结
工具名处理速度数据完整性价格推荐度SQLyog★☆☆☆☆★★★★★★★☆☆☆★★☆☆☆Navicat Premium★★★☆☆★☆☆☆☆★☆☆☆☆★☆☆☆☆Mss2sql★★☆☆☆★★★☆☆★★★★☆★★★☆☆DB2DB★★★★★★★★★★★★★★★★★★★★
以上四款软件中最不推荐使用的是 Navicat Premium主要原因是数据的完整性表现较差转换后的数据不能立即用于生产环境需要程序员仔细自行查找原因和分析。而 SQLyog 有较好的数据完整性但整体处理速度非常的慢如果数据较大的情况下需要浪费非常多宝贵的时间。比较推荐的是 DB2DB软件整体表现较好对我来说最重要的是在不购买的情况下也够用了而且全中文的傻瓜式界面操作起来实在方便。
