本文来自阿里云数据库团队内核组
最近有较多的客户系统由原来由Oracle改造到MySQL后出现了性能问题CPU 100%，或是后台的CRM系统复杂SQL在业务高峰的时候出现堆积导致业务故障。
在我的记忆里面淘宝最初从Oracle迁移到MySQL期间也遇到了很多SQL的性能问题，记忆最为深刻的子查询，当初的版本是MySQL5.1，这个版本对子查询的优化较差，导致了很多从Oracle迁移到MySQL的系统出现过性能问题，所以后面的开发规范中规定前台交易系统不要有复杂的表join。
接下来我将列举一些常见从Oracle迁移到MySQL过程中可能出现问题的点：
1). 当客户进行去O数据迁移时，存在必须改、不用改和可改可不改的三大类SQL。对于可改可不改的，我们应提供一些指导性的建议，帮助用户规避将来碰到可能存在的问题。
2). 指导数据库研发人员、数据库管理员合理使用MySQL，发挥MySQL最优性能。
1 并行处理 1.1 背景介绍Oracle能够将一个大型串行任务（任何DML，一般的DDL）物理的划分为叫多个小的部分，这些较小的部分可以同时得到处理，最后将每个较小部分得到的结果组合起来得到最终结果，所以Oracle在OLAP的应用场景中可以利用并行处理技术来运行非常复杂的SQL查询。
启动并行查询几种方式：
(1)、在查询中使用一个hint提示：select /*+ parallel(4) / count() from test_a ;—指定一个并行度为4的并行查询。
(2)、利用alter table修改表：alter table test_a parallel 4;–告诉oracle，在创建这个表的执行计划时，使用并行度4。
1.2 改造建议由于MySQL不支持并行处理，所以当应用从Oracle迁移到MySQL后，需要特别注意使用了并行处理的SQL语句。处理建议：
(1)、在阿里云平台上可以使用ADS这样的分析型数据库产品来处理Oracle中的并行分析查询。
(2)、将复杂SQL语句进行业务分解，拆解为单条的SQL语句，将计算结果放到应用中进行处理。
2 SQL执行逻辑读，物理读，消耗时间 2.1 背景介绍对比MySQL的优化器，Oracle的优化器有着丰富和完善的优化算法，仅表连接上Oracle支持nested loop、hash join、sort-merge join三种算法 ，而MySQL仅仅支持其中的nested loop算法，所以在一些大表关联以及多表关联的复杂查询中MySQL的处理能力会明显下降。那该如何去鉴别一些不适合迁移到MySQL的查询？可以根据SQL执行中的一些关键数据：逻辑读，物理读，消耗时间来判断。
物理读：把数据从数据块读取到buffer cache中。
逻辑读：指从Buffer Cache中读取数据块。
执行时间：Oracle执行一条SQL所消耗的时间。
(1)、第一次查询一个表t
select * from t ;
(2)、第二次查询：
select * from t；
第一次查询有6次物理读，第二次查询有0个物理读，6个逻辑读。当数据块第一次读取到,就会缓存到buffer cache 中，而第二次读取和修改该数据块时就在内存buffer cache 了。
Oracle性能调优中，逻辑读是个很重要的度量值，它不仅容易收集，而且能够告诉我们许多关于数据库引擎工作量的信息。逻辑读是在执行SQL语句的时候从高速缓存中读取的块数。
MySQL对于简单的SQL语句执行是非常快的，对于Oracle应用中逻辑读，物理读或者执行时间非常高的SQL迁移到MySQL后则不在适合了，需要进行改造：
(1)、单表查询逻辑读，物理读和执行时间比较长的情况，SQL可能发生了全表扫描（dump需求）或者索引不优，可以使用只读节点来承受dump或者对索引进行优化。
(2)、多表查询逻辑读，物理读和执行时间比较长的情况，可以使用ADS分析型数据库产品来处理；
(3)、多表查询逻辑读，物理读和执行时间比较长的情况，可以进行业务分解，拆解为单条的SQL语句，将计算结果放到应用中进行处理。
备注： 逻辑读和物理读如果超过100W，执行时间超过5S，则属于较大的SQL查询。
3.In (…..) 3.1 背景介绍Oracle中对in(….)的参数限制是1000个，在MySQL中虽然没有个数限制但有SQL长度的限制，同时优化器在对in(…)的查询进行优化的时候采用二分查找，所以in(…)的个数越多性能会越差，所以建议控制in的数目，不要超过100个。
3.2 改造建议Oracle：select * from t where id in(id1,id2…..id1000);
MySQL：select * from t where id in(id1,id2…..id100);