开源MySQL向分布式数据库转型，采用哪种技术方案兼容性最好、代码改动最小？
目前应用（非核心交易业务）采用的是开源mysql，计划向分布式数据库转型，请问采用哪种技术方案，兼容性最好、代码改动最小，有什么推荐，谢谢。
6同行回答
提问信息：
目前应用（非核心交易业务）采用的是开源mysql，计划向分布式数据库转型，请问采用哪种技术方案，兼容性最好、代码改动最小，有什么推荐
问题简化：
1、 应用（非核心交易业务）采用的是开源mysql，计划向分布式数据库转型？
答：
（1）从描述的应用为非核心交易业务，是单库版本MySQL数据库，用于尝试转型分布式数据库架构。
（2）本次尝试是为今后其他业务系统的数据库架构转型的产品选型尝试，则建议明确企业是否要求OLTP分布式数据库产品必须跟集中式数据库产品 在实时数据一致性、悲观锁、死锁检测、死锁解除、全局序列、全局唯一约束、事务隔离级别等是否保持一致，也即对业务系统的数据架构设计者 和 研发工程师 保持主体习惯不变。
2、 请问采用哪种技术方案 ？
答：
（1）选择何种技术方案 不是第一重要的，而是明确产品选型的目标要求为第一要素，即： OLTP分布式数据库产品必须跟集中式数据库产品 在实时数据一致性、悲观锁、死锁检测、死锁解除、全局序列、全局唯一约束、事务隔离级别等是否保持一致，也即对业务系统的数据架构设计者 和 研发工程师 保持主体习惯不变 。
（2）何种技术方案能达到产品选型的目标要求。
（3）选择的技术方案 除业务系统的设计者和研发者之外，是否在数据库运维管理方面、数据库技术知识储备、数据库人才市场上DBA招聘或培养的难易程度。
建议从上述三个维度出发，也即关心 数据架构设计者、研发工程师、数据库运维工程师。
3、 兼容性最好、代码改动最小，有什么推荐 ？
答：
（1） 代码改动最小 ：就是要达到同集中式数据库MySQL/Oracle等一样效果的“ 实时数据一致性、悲观锁、死锁检测、死锁解除、全局序列、全局唯一约束、事务隔离级别等是否保持一致，也即对业务系统的数据架构设计者 和 研发工程师 保持主体习惯不变 ”
（2） 兼容性最好 ：选择存储引擎依然是MySQL开源数据库 或者 直接采用InnoDB存储引擎，也即内在就是融入MySQL数据库生态的产品兼容性最好，像阿里云DRDS、热璞数据库HotDB就是把MySQL开源数据库作为存储引擎来用。
（3） 有什么推荐 ：建议从企业需求维度出发，然后找3家左右分布式事务数据库厂商来测试验证，推荐找对外宣传支持上述目标要求的数据库厂商，例如：中兴GoldenDB、腾讯TDSQL、热璞HotDB、阿里云DRDS、华为DDM，MyCAT开源分布式数据库等衍生产品则因不支持分布式事务、死锁、唯一约束等功能则直接放弃。
备注：找分布式事务数据库产品厂商测试则要求可参考马上公布的金标委的金融分布式数据库检测方案，确保能判断产品是否达标，甚至某些地方更苛刻。也可以参考下信通院标准：http://www.talkwithtrend.com/Document/detail/tid/433099
收起
分布式数据库实现方案大致分两类：一类是自研分布式数据库，另一类是开源数据库 + 中间件的模式。
贵行已经用了开源mysql，从成本上来说，直接用开源mycat可能更节约一些， 用mycat来实现水平扩展、读写分离、分库分表等能力。但是这么做也有隐形风险，一要看业务sql、事务是否适合做分布式改造；二要评估贵行的人力投入，mycat策略需要手动配置；三是这么做的话可能最终还是一个业务系统一套数据库的模式，并没有真正实现分布式数据库统一管控的目标。
若是采用自研分布式数据库，那就要做好poc测试选型了， 以下几个关键要素，作为选型的参考：可扩展性、高并发性、高可用性、支持分布式事务、易于维护、兼容性。此外， 有的企业比较看重自主可控。还需考虑迁移改造成本。在选型时一定要考虑原数据库迁移至分布式数据库的改造成本，包括 sql 语句、数据迁移等方面的改造难度和改造工作量，也包括与分布式数据库匹配的硬件投入（某些分布式数据库对于硬件的要求比较高，硬件会影响数据库性能。）建议选一两个典型业务系统，做兼容性和改造量的评估测试。
没有绝对的答案，要通过测试来评估最适合贵行的产品。