传统的中小企业应用中，使用oracle的系统占比较多。迁移到云环境mysql数据库的情况下，需要考虑诸多因素，可用性、效率等。针对阿里云上的系统迁移情况来看，中小企业为主，迁移的应用数量比较大，所用技术五花八门，人肉处理的工作量非常大，效率较低。

1.整体思路

最主要的思路是：

1. 先考虑可用性、跑起来，DDL+数据迁移，基本的DML，程序的修改和调整，
2. 再考虑高性能高可用高扩展，性能优化，分库分表支持，
3. 中间可以积累一些通用的框架和平台工具，比如：
   • 数据库反向建模与DDL生成，基于EMF、GMF之类的
   • 程序的SQL扫描处理，自动发现
   • DML转换工具，基于下面第二节的考虑要素
   • 数据迁移工具，这个应该相对比较成熟
   • 在线性能度量和优化工具，这个阿里应该也有积累
   • 将上述工具平台化，并串起来，自动评估企业应用的去O上云复杂度，评估成本
4. 长期来看，应该基于一些友商，比如用友、金蝶、中软、中科软、中科软等一些固定产品做一些封装和深度定制合作，解决同一类平台上的不同应用系统的去O工作。
5. 对于特定的一些行业信息化系统，也有一些类型特点，可以积累一些行业类的迁移解决方案。

2.数据库修改

DDL

• 反向成模型，再生成mysql或其他数据库，主要是数据类型转换，主外键、约束
• 处理sequence与自增

DML

必须改、可以改可以不改、不用改

触发器、存储过程

• 避免，如有需要重写，考虑sql或代码里重写

3.程序修改

• 写在代码里的SQL拼装，全文检索或语法分析获取
• 写在xml里的mapping
• 写在HQL类的转换引擎隐式SQL
• 扫描代码、properties和xml
• JDBC驱动、druid等proxy拦截SQL，系统日志过滤SQL
• 尽量单表的简单操作，便于移植
• 如果原先代码里没有用ORM类框架，可以使用快速的脚手架，这套脚手架可以快速的应用到不同的目标数据库，通用性的编程性基础设施都应该是一致和完备的，类似hibernate的思想。

4.数据迁移

全量+增量

5.性能

优化应该积累成规则，一起做到框架中去，最好能在运行期收集指标信息，持续动态优化，

hint

子查询

函数与索引

6.扩展性

分库分表

7.应用场景

这些工作经过积累沉淀为平台工具后，可以开源出来大家共同维护，也可以在阿里云上作为自助服务式的在线工具，提供给中小企业的技术人员直接操作转换自己的线下应用到云上。
另一方面，企业内部可能有多种不同的孤立数据源，经过这些工具转换以后，可以比较容易的在阿里云上进一步进行数据的整合，形成企业大数据中心，作为发展企业大数据的出发点。

补充：与阿里云去O团队沟通了解，目前做的工作大概就是这个思路，很多东西比这些要更深。