话说，这几年折腾数据库真是没少掉头发。我手头有个老系统，说起来都快奔十年去了，一直都是跑在Oracle上面的。稳定是稳定，没得说，但时间久了，就觉得有些地方不那么方便了，特别是想着以后扩展啥的，Oracle的授权费用也挺让人头疼的。我就琢磨着，能不能把它挪到MySQL上去，毕竟MySQL社区版免费，灵活度也高。
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.icu
这念头一出来，我就开始在网上各种找资料，看有没有什么好用的工具能帮我把这活儿干了。当时我可不想自己写一大堆脚本去倒腾，那得多累。网上各种工具看了个遍，有付费的，有开源的，还有那种看着界面就觉得很傻瓜式的。我这人嘛喜欢自己动手，但更喜欢用“巧劲儿”，能省事儿就省事儿。挑了个看着顺眼的工具，名字我就不说了，反正这类工具网上挺多的，功能都大差不差。
动手前的准备工作
光想着可不行，得干！
- 第一步，备份！ 这个是老生常谈了，但真的太重要了。我先把Oracle那边所有的表空间、数据文件，甚至控制文件，都仔仔细细地备份了一遍。万一迁移失败了，或者数据丢了，还有退路。这个步骤，我可是不敢掉以轻心。
- 第二步，摸底Oracle。 接着我把Oracle里所有的表结构、索引、视图、存储过程、触发器，甚至包括序列，都跑SQL脚本导了一份出来，好好研究了一下。特别是数据类型，Oracle的VARCHAR2和NUMBER啥的，到了MySQL里得变成VARCHAR和INT/DECIMAL，这些心里得有个数。
- 第三步，搭MySQL环境。 我在测试机上装了个干净的MySQL数据库，版本也选好了，跟以后生产环境要用的一致。建好库，设置好用户权限，一切都准备妥当。
- 第四步，安装工具。 我把那个选好的数据迁移工具，从官网下载下来，一路“下一步”安装好了。这工具一般都带客户端界面，用起来比较直观。
正式开搞，数据迁移详细步骤
所有的前期工作都做好了，我就开始正式“搬家”了。
我打开了那个迁移工具。它的界面通常是这样：
- 连接源数据库。 我先在工具里找到了“连接源数据库”的选项，然后输入了Oracle的IP地址、端口、服务名（或者SID）、用户名和密码。点了一下“测试连接”，看到绿灯亮了，心里踏实了一截，说明跟Oracle那边“握手”成功了。
- 连接目标数据库。 我点了“连接目标数据库”，同样的操作，输入了MySQL服务器的IP、端口、库名、用户名和密码。测试连接，也是“连接成功”，这下跟两边数据库都搭上桥了。
- 扫描和分析。 工具连接好两边数据库后，它就开始自动扫描我的Oracle数据库了。哗一下子，Oracle里所有的表、视图、存储过程这些对象，全都密密麻麻地列了出来。工具还会自动分析这些对象的结构，以及它们之间的一些关联关系。
-
映射和转换。 这一步是整个迁移过程中最关键的。工具会把Oracle里扫描出来的对象，自动映射到MySQL里对应的类型。比如Oracle的VARCHAR2(100)就会自动映射成MySQL的VARCHAR(100)，NUMBER(10,2)会变成DECIMAL(10,2)。但有些地方我还是得自己盯着点。
- 数据类型调整： 比如Oracle里有些特殊的CLOB、BLOB类型，工具可能会建议我转换成MySQL的TEXT或BLOB。我对照着之前做的笔记，仔细检查了一遍，有些地方觉得工具默认的不太合适，就手动改了一下。
- 主键和自增ID： Oracle里的主键通常都是用序列（SEQUENCE）来生成自增ID的。到了MySQL，就没有序列这说法了，得用AUTO_INCREMENT。这个工具还挺智能的，它能识别出哪些字段是主键，并且是依赖序列的，然后自动帮我勾选了MySQL的AUTO_INCREMENT属性。我当时看到这里，心里就美滋滋，省了我不少事。
- 索引和约束： 索引、唯一约束、外键这些，工具也基本上能自动识别并进行转换。我就抽样检查了几张关键的表，确保它们的索引在MySQL里也能正常创建。
- 存储过程和触发器： 这个就比较麻烦了。Oracle的PL/SQL语法跟MySQL的语法差异挺大。工具对于这块儿，一般也就是“尽量转换”，大部分时候还是得我手动改。所以这块我是单独处理的，先导出来，然后根据MySQL的语法一点点重写。但这回数据迁移的重点是表和数据，所以这部分我先放了放，想着等数据都过去了，再慢慢搞应用层面的。
- 开始迁移数据。 确认了所有的映射和转换规则都没问题后，我就壮着胆子点了那个“开始迁移”的按钮。那一瞬间，心里还真有点小激动。屏幕上就开始刷日志了，显示着一张表一张表地创建，一条条数据地导入。看着进度条一点点往前走，心里的石头也慢慢放下了。
- 处理错误。 过程中肯定会遇到点小插曲。比如某张表的某个字段，因为源数据里有特殊字符，或者字符集不兼容，导致迁移报错了。我就停下来，回去检查Oracle里的原始数据，或者调整MySQL的字符集设置，然后选择只重新迁移那张报错的表。反复折腾了几次，总算是把所有的数据都顺利地导过去了。
数据迁移后的检查和收尾
等到工具显示“所有数据迁移完成”的时候，我赶紧打开了MySQL Workbench，开始仔仔细细地检查起来。
- 检查表结构： 我先是挨个库挨个表地看，对照着Oracle那边的结构，看看MySQL里字段名、数据类型、主键、索引、默认值这些是不是都对上了。
- 抽查数据： 然后我跑了几条SQL，随便从几张大表里抽了几条数据，跟Oracle里对应的记录做了比对，确保数据内容是一模一样的，没有乱码，也没有截断。
-
核对行数： 最关键的一步，我写了个简单的脚本，分别在Oracle和MySQL里，对每一张表都跑了
COUNT()，把两边的行数一对比。看到所有的表行数都能对上，我这心里的大石头才彻底放了下来。那一刻的成就感，真是无以言表。
数据都确认没问题后，我没急着把老系统彻底切换到MySQL上。而是先在测试环境里，把我的测试应用连上了新的MySQL数据库，跑了几天，模拟业务流程，确保所有的功能都正常，没有因为数据库的变化而出现异常。等到一切都稳稳当当了，才敢把生产环境的应用，正式切到了MySQL这边。
整个过程下来，虽然说这个迁移工具帮了我大忙，省去了很多手动编码的麻烦，但自己心里还是得有数，不能完全当个甩手掌柜。特别是数据类型转换、一些特殊对象的处理，以及最终的数据校验，这些都是必须自己亲自把关的。这回迁移，让我对Oracle和MySQL两个数据库的细节差异又有了更深的理解，也算是又给自己涨了点“经验值”。以后再遇到类似的数据迁移，心里就有谱多了。