【前言】
近年来，各大行业去O运动愈演愈烈，一方面是基于对数据库安全可控的考虑，另一方面分布式数据库逐渐占据了OLTP领域较大的市场，尤其在互联网领域，MySQL、PG等分布式数据库的应用非常广泛。
在进行Oracle向MySQL迁移时会遇到很多难点，那么，从Oracle迁移至MySQL会遇到哪些问题？这些问题是否能顺利解决？
一、为什么是MySQL？
MySQL具备如下优势：
-
丰富的实践经验和蓬勃生态，阿里等行业巨头已成功地使用MySQL替
换Oracle并支撑了庞大的业务。
-
支持行锁和事务的Innodb存储引擎越来越强大，对于高并发下OLTP
优势明显；
-
灵活的逻辑复制搭建主从可以在架构设计上有更多的空间。
-
丰富的开源中间件搭配MySQL可以提供更高的业务需求。
二、Oracle数据能否无损迁移至MYSQL数据库？
首先需要非常熟悉MySQL和Oracle的差别，如果单纯的考虑表的数据，那么需要详细对比不同数据的字段类型的兼容性。迁移前需要梳理清楚，应该就不会有太大问题。
另外需要考虑迁移后的维护问题，高可用的方案，而不是单纯的说无损迁移。
DSG的同步软件也能进行数据的迁移，但是在实际使用中，用DSG的来做全库的初始化效率稍微有点差。
三、Oracle数据库迁移至MYSQL过程中如何保障系统稳定性？
很大程度上取决于能多大程度上接受业务中断。
正式迁移前需要反复测试、试运行，尽可能保证正式迁移稳、准、快。如果业务允许可以尝试切割方式，分几次迁移，两边都同步运行一小段时间。
也可以在应用层面控制数据一致性，通过应用双写，确保异构数据库都能运行正常，最后停掉迁移之前的DB。
四、数据一致性还比较容易保证，业务逻辑（存储过程、触发器、自定义函数等）方面如何改造，兼容性如何保障？
遵循以下原则：
五、Oracle迁移至 MYSQL表的限制、数据类型映射关系，如何处理？
Oracle->MySQL的对照表:
| MySQL | Oracle |
| bigint | number（19,0） |
| bit | raw |
| blob | blob，raw |
| char | char |
| date | date |
| datetime | date |
| decimal | float（24） |
| double | float（24） |
| enum | varchar2 |
| float | float |
六、Oracle与 MySQL的 SQL语法有很多不兼容的地方，有哪些合适的工具可以快速完成 SQL的转换？
MySQL语法要完全兼容Oracle的语法是一件非常困难的事，目前业内兼容Oracle做的比较好的应该是EDB了。
阿里云号称兼容Oracle的PPAS实际上就是EDB，从实际的测试来看，也还是有很多不尽如人意的地方。
所以想完全实现自动转换，基本上没这个可能。不过部分的兼容是可以实现的，
七、Oracle与mysql 有些语法、数据类型等略有不同，迁移过去后是否必须要逐条修正？
迁移前期，Oracle 与 MySQL的 SQL语法兼容性，数据类型间的映射关系就要提前测试验证好。
原则就是在测试环境使用准生产数据进行不断地迁移演练，不断改善迁移中越到的类似问题。
八、Oracle数据库迁移至MySQL数据库后，上层应用是否需要修改，修改的方面有哪些？
是否需要修改以及修改哪些内容，这些都非常依赖目前应用是如何使用Oracle的。不管什么业务和使用情况，都需要修改几点是：1.数据类型。Oracle和MySQL不一样的地方。2.访问数据源驱动。譬如JDBC。3.部分SQL写法。
九、Oracle数据库迁移至MySQL数据库后，还能逆向回迁至Oracle数据库么？
理论上和实践上都是可以的。