从Oracle迁移到MySQL需要考虑的远比我们要梳理数据类型转换的技术细节更重要，更重要。有两个问题需要提前考虑：为什么要从Oracle迁移？为什么要迁移到MySQL？阐明。问题一：为什么要从Oracle迁移？从行业实践（主要是互联网行业）来看，这件事情首先肯定不是技术上的可行性，而是商业上的可行性。说到底，主要的出发点就两个字：成本。MySQL是开源免费的，更重要的是在行业实践中得到了充分的验证，具有得天独厚的优势。阿里去IOE在很多年前就很火了，现在看来已经成为了行业的一个标杆。成本这件事很微妙，不是三言两语能说清楚的。例如，您可以使用Office来工作。当然，你可以考虑购买license或者绿色版激活，但是如果你用WPS，也是情有可原的。当然，在功能上与Office有一些差距，但不会有模糊的界限。从商业的另一个维度，想象一下我们接触的互联网行业。除了充值和钱相关的??业务，在很多业务中，对数据完整性和一致性的要求都会降低一个维度。很多时候，钱能解决的问题都不是问题，有什么比钱更重要的，我觉得应该是安全，安全包括生命安全，行业安全，系统安全，这些是绝对不允许有一些重大的问题，这些影响太大，比如医院医生给病人开药的数据，这些影响是非常大的，一旦出了问题，很容易成为公共事件。以金融级业务为分界点，上面的区域是安全领域，下面的领域其实是一些可选的空间，非常大。选择创业的原因之一也在这里。有了技术后盾，这些成本对于企业来说也需要绑定到厂商身上。如果出现问题，没有专业快速的支持，那就是悲剧了。然后是开源定制。其实很多开源技术的开源协议都是不一样的。我们在采用开源技术的时候，还需要考虑这些协议的边界和适用范围。所以这里需要明确的是：1、成本因素需要权衡，绝对不是非黑即白的事情。2、迁移到MySQL其实不是最好的方案，而是一个可选的方案。3.足够的开源技术积累4.迁移的本质是找到最适合的业务场景，而不是技术实现。以第4点为例，Oracle的性能是毋庸置疑的，但是如果有海量的Read请求其实不适合Oracle来处理，当然也不适合MySQL。也许Redis解决方案会更好。问题二：为什么要迁移到MySQL要回答这个问题，其实我们的主线就是MySQL能做什么。***还是成本，开源免费，易于定制，MySQL的选择肯定不仅仅是社区版，还有一系列的分支，比如Percona分支，MariaDB分支，存储引擎InnoDB，MyRocks等等。都是免费选项。二是MySQL足够高效和轻量级。从MySQL的效率来看，学习周期会很短，简单易上手，对系统资源要求不高。三是横向扩展能力。如果把Oracle比作地铁，把MySQL比作公交车，就更容易理解了。我们可以很容易地添加公交线路，但是添加地铁线路是完全不同的。我觉得这是迁移到MySQL的一个核心点，这也是为什么很多网上MySQL的规模往往是几百上千，业务的爆发式增长，MySQL的扩展能力不是体现在MySQL数据库本身，而是在架构中。在可扩展性方面，这是许多MySQLDBA的成本更高的原因之一。第四是复制。这是MySQL相对于Oracle的一个亮点。如果需要做跨数据中心的复制，允许有一定的延迟。使用MySQL的本机复制解决方案非常容易。MySQL支持许多不同的维度。复制方案。五是业务依赖轻，分为两个维度。一个是功能限制，另一个是性能限制。这本身就是MySQL在功能和性能上的不足，但却是一个优势，因为要支持分布式需求，业务需要更加依赖数据库，原本不支持的存储过程自然可以弱化。第六是开源带来的生态。开源红利给企业带来了很多技术方案的选择，让原本需要花钱买的东西变成了我们自己用的东西。问题三：从Oracle迁移到MySQL首先要考虑的是架构上的差异。Oracle和MySQL之间的区别是相当大的。当然Oracle中也可以使用同义词的架构来实现类似MySQL的访问模型。数据类型的不同其实是更具体的技术细节，我会做一些补充。Null和空字符串在oracle中都可以当作null来处理，但是在MySQL中这两者是不同的。oracle表名和用户名有长度限制，30个字符以内，MySQL中长度要大很多，尤其是表名需要注意。在oracle中默认按大写处理，在MySQL中默认区分大小写。对于MySQL的类型，MySQL中需要考虑的细节很多，比如数值类型，Oracle中的数字是可以固定的，MySQL有一系列的数值类型可以选择。不建议统一bigint适应所有需求。为了更清楚地回答注意事项，可以归纳为一个问题：MySQL相比Oracle缺少什么？性能肯定有区别，我们主要看功能。比较的原则不是Oracle一定要有MySQL，而是它在某些使用场景下有更好的使用特性。存储过程支持有限。这是很多企业的技术债。处理得好，就是一条坦途，处理不好，就是一个大坑。比如存储过程，如果硬要用存储过程调用来连接，后面会后患无穷。没有同义词，也没有数据库链接。MySQL不支持这个特性其实是件好事，这样就不用跨库关联了。没有sequence，这个mysql的自增列可以弥补。没有物化视图，很难实现增量刷新的需求。分区表是有的，但是很少用到。优化器薄弱，多表关联，HashJoin仍然是MySQL的软肋。索引的差异，覆盖索引的实现也大不相同。绑定变量的性能差别不大，Oracle中敏感的绑定变量问题在MySQL中不是问题。性能工具，MySQL中的性能工具还是比较少的，粒度和作用有限。总结一下：迁移的本质是找到最适合的业务场景，而不是技术实现。
