传统数据库痛点
说起分布式数据库，必须先提一下传统单机数据库。以大家较为熟悉的MySQL 为例，如下图所示，传统单机数据库架构简单，由若干台节点通过Binlog 复制构成一个集群，写集中在主库，读则分摊在集群的各个节点上。
不可否认的是，上述架构在一些重要特性上存在“天花板较低”的问题，如以下5个特性。
特性 1 ：高可用问题。
MySQL 本身是不具备高可用能力的，它的高可用能力通过外部工具协助达成（MySQL 高可用方案随着复制的改进有漫长的演化历史）。众所周知，高可用工具往往只能最大限度解决数据一致性的问题，而不能解决HA 切换后应用访问的问题，通常一个完整的高可用系统是要HA 工具+Proxy 联动+ClientDriver 连接池合理配置共同实现的。遗憾的是，时至今日不少中小公司并没有丝滑解决HA 切换的问题，主要原因是HA 工具+Proxy 深度定制能力欠缺，篇幅原因不做展开。
特性 2 ：数据一致性问题。
数据复制是存在时差的，造成读一致性问题，但这通常不是太大的问题，通过Proxy bindmaster 操作都能解决，不过，master 压力可能会同样面临性能瓶颈。
特性 3 ：容量、性能扩展、结构变更。
这是传统单机数据库的三宗罪。存储的扩展在一定程度内可以通过堆硬件（垂直扩容）的方式来解决，但堆硬件也是有限度的，出于可运维、易运维的角度，通常DBA 都不会让单实例或者单表太大。可能对于一个冷的日志表存储超过1TB DBA 可能就会比较紧张了，毕竟DDL 一次可能要以天计算，而对于一个读写高频的订单表超过500GB ，估计DBA 维护就会如履薄冰瑟瑟发抖了！这时棘手的问题就来了：给够你硬件你都不敢用。
通过堆硬件能在一定程度上缓解存储容量上限的问题，但性能问题是无法靠堆硬件完全解决的。还以订单表为例，如果是日订单百万甚至千万级别，无论怎么折腾单表都会出现严重的读写性能问题，此时通过扩容硬件的方式不能解决问题。一方面是因为数据库本身会由于热点表的高频读写造成严重的锁放大问题，另一方面数据库本身并不能充分使用硬件资源，尤其MySQL 5.6 之前的版本由于诸多子线程未从Master 主程上拆分，造成CPU 使用不充分，这在MySQL 5.7 版本后有了很大的改观。尽管如此，还是会受到网卡、磁盘IOPS 上限因素的影响，注定单机构成的数据库集群存在性能上限。因此不幸的是：给你足够的资源你都用不到。
不敢用、用不到都很痛苦！为此就诞生了“ 拆” 的想法，根据不同的“ 拆” 法诞生了不同形态的分布式数据库。值得一提的是今天做数据库拆分的初衷并不是为了解决性能瓶颈而是数据存储达到单机上限，更直白一点地说，拆的关键是解决大表运维困境。
特性 4 ： HTAP 。
新时代赋予数据处理新的诉求，目前解决方案还是通过数据流（ETL ）的方式将数据写到其他分析型数据库中。不管是链路维护复杂性还是应用健壮性（低延迟、高稳定性）都有不小的麻烦。因此，希望能通过一套数据库搞定所有问题。
特性 5 ：容灾能力。
近几年企业对容灾的要求越来越高，作为DBA 也应当确保极端情况下（机房限电、被炸等）数据库具备逃逸能力。单机数据库通过主从（异地部署）方式也能实现，虽然维护较为复杂但也能用。
分布式数据库形态划分
分布式数据库根据不同“ 拆” 法或者设计理念大致有如下三种形态划分。
1、分布式中间件
典型的架构图（简化图），核心思想是通过中间件将多个独立的物理集群组联合起来构成一个逻辑集群，通过某种数据路由规则将用户请求打散到不同节点上。
该做法俗称分库分表，是绝大部分互联网公司在解决容量、性能扩展性问题上的首 选方案。该方案将数据基于某种规则（sharding key ）均匀拆分到多个集群中来达到分摊存储与计算性能压力，代表的中间件产品TDDL/Cobar/Vitess ，及基于该思想诞生的“ 分布式DB” 代表产品TDSQL 、StarDB 等。这类方案虽然解决了容量、性能可扩展的问题，但是也存在如下的一些问题。
问题1：技术复杂。
通常是大公司专属玩法，普遍基于业务场景做了深度定制，周边有一套完整的配套管控系统支持。目前市面上虽然有一些开源的Proxy 也能用，但对于中小公司来说很难从根上可控，使用过程中的棘手问题几乎很难在短时间解决，而且开源产品为了通用性要想基于公司场景化定制有难度。因此，很多中小公司虽然做了分库分表但或多或少存在这样那样的问题。
问题2：对业务有侵入。
从单表到分库分表的改造普遍要求带sharding key 作为数据拆分及路由依据，这样业务逻辑*进行改造，比如对多表join 的场景很难通过中间件去解决、非sharding key 的查询*要扫片性能则非常低、排序/ 分页/ 聚合计算问题，等等。为了解决数据拆后聚合的问题，通常要在整个业务链路上部署复杂的中间件，这给稳定性维护及业务健壮性带来一些挑战。
问题3：扩缩容复杂。
通常在决定分库分表的时候需要提前做好容量评估，分片数定义好后就不在改变，非常不推荐后期再去扩展/ 缩容分片数。调整（reshard ）分片数涉及数据rebalance 整个过程。为了保证数据一致性要做很多额外工作，通常是DBA 定制开发一个平滑迁移工具，或者研发双写+ 增量Binlog 数据订阅做数据同步。如果reshard 操作能内置到中间件，那对研发及DBA 来说自然更友好，但目前市面上开源的中间件几乎没有见到有类似的功能！诸如TDSQL 、StarDB 等从公开资料上看是具备对用户透明的reshard 能力的。
问题4：分布式事务问题。
出于对ACID 完整性支持的考虑，由中间件形态构成的分布式数据库中解决分布式事务问题，通常解决方案都是差不多的，即两阶段提交（2PC ）。
但实现过程非常复杂，也不可避免的对性能造成影响，通常在该形态的分布式数据库中都不太推荐用分布式事务。此外，这里分布式事务不能保证数据一致性或者说对集群而言本质还是最终一致性，该形态的分布式数据库在分布式事务实现上普遍类似，可以参考分布式中间件Seata 的实现原理。
对于中小公司可行的做法是业务场景拆分得足够简单的情况下基于代理中间件+ 业务数据补偿来保证数据的最终一致性，使用分布式框架如Seata 也是可行的，但太重了，对性能也会有明显的影响。
问题5：运维复杂性。
分布式中间件形态的数据库往往都有非常完善配套的管控系统来打包解决常见的运维问题，如果公司是基于某个开源的代理中间件做的，则不可避免的也要开发相关的管控系统来统一解决诸如DDL 、研发数据订正等问题。整体上还是能很好解决存储、计算能力不足等问题和大表运维困境，只是对业务会有入侵，大公司专属定制，中小公司勉强也能玩转。
问题6：HTAP。
目前看到的分布式中间件形态的数据库基本不具备OLAP 的能力，普遍做法还是要将数据流向到分析型数据库中。
问题7：容灾能力。
跟单机主从无本质区别
2、存储计算分离
该形态的分布式数据库核心思想是计算、存储分离，计算与存储解耦，将有状态的数据和日志下推到分布式存储，多个无状态计算节点共享一份数据，代表产品AWS Aurora 、阿里PolarDB 。
这里简单看一下Aurora 对性能、容量、结构变更上的优化。
首先在性能上，the log(redolog) is the database ，简单说Aurora 没有直接存储MySQL 的innodb page 数据页，只有一份redolog 日志（个人理解应该是区别于innodb 的wal ，最多是概念的相似，没有做深度考证），当需要读取数据时将redolog 转换为data page 。这样设计由于只存储了一份redo 数据（批量+ 顺序I/O ）无需写data page 因此也不存在缓冲区刷脏跟随机I/O 写的问题，这相比于MySQL 写I/O 放大要精简很多，因此性能要提升很多。引用公开资料结论：事务I/O 开销只有MySQL 1/7 事务处理能力是MySQL 的35 倍。
不过有利就有弊，Aurora Server 层还是原汁原味的MySQL Server （100 % 兼容原生MySQL ），读取数据时不可能直接读取redolog ，需要将redolog 转换为data page ，转换是要支付CPU 代价的。当然基于该特殊设计还有一些其他比较好用的功能如秒级备份（俗称拍快照），就不多介绍了。
其次在容量上，存储构建在S3 共享存储之上，对于容量扩展可以支撑足够大的数据量(64TB) ，多个副本之间通过Gossip 协议保障数据一致性的，得益于S3 的设计副本间的数据同步是非常高效的，因此副本间的数据延迟非常低。笔者在写该文档时顺便查了一下当天的副本延迟监控P90 居然都不到1s ，对比原生MySQL 即使是优化后的GroupCommit+MTS 也很难做到这一点。
值得一提的是，正是基于log is data 的设计+S3 log 同步避免了多数据副本间为数据一致性采取的2PC/3PC 提交或者更复杂的Paxos 算法，非常niubility 的设计。最后Aurora 的存储容量是弹性伸缩的，DBA 无需主动扩容，不过从使用经验上看，在业务释放空间后似乎并没有做“ 缩” 的动作，会继续按照此前实例使用的最大存储来计费（略坑），这点目前不清楚具体原因是啥！
在结构变更方面，目前跟原生MySQL 一样也是fast ddl ，在lab mode （实验室模式默认关闭状态，官方不推荐用…… ）支持Instant ddl ，不过只针对add column 操作，目前DDL 操作其实还是以pt-osc/gh-ost 为主。虽然大表容量的问题解决了但对于超大表的运维还会存在一定的问题。即使通过pt-osc/gh-ost 能丝滑变更，以及MySQL 没有明确规定单表大小及行数上限，但出于b-tree 的原因在行数过多后还是会影响到读写性能，笔者在实际使用过程中就出现了一张400G 的单表DDL 超过12 小时的情况，为此发布系统不得不block 这个表的发布长达一年的时间。存储计算分离的形态下，尽管架构是分布式的，在具体的设计思想上也非常先进，但对于解决大表问题还是稍稍有一点小遗憾，不过相比传统单机数据库已经不用担心容量问题了，这一点对于业务体量不大既不想用中间件也不想对业务动刀的公司而言似乎也是不错的选择，况且SQL 协议100 % 兼容。
此外，通过将计算下推到分布式存储的多个存储单元上实现并行查询从而具备一定的分析能力，也很难满足分析型场景要求。不过， 存储计算分离的形态天然具备同城+ 异地容灾能力。
在使用Aurora 的使用体感上，笔者更倾向于把它当作一个不宕机的容量性能无限扩展的单机数据库来使用，当业务体量到一定程度后出于易维护的角度考虑，最后大概率还是要拆的。最后建议如果中间件能力缺乏又不想因拆导致的后续一堆麻烦的问题，即使维护麻烦一点也可以继续使用。
PolarDB 与Aurora 类似，也采用了存储计算分离架构，因此也能很好解决容量、性能问题，同时也做到100 % 的协议兼容与较低的数据延迟，至于谁优谁劣，由于二者设计理念不同，以及个人水平有限，不做过多评价跟分析。
PolarDB 在比较关心的大表解决方案上做了优化增强，主要解决方法就是通过分区表，如分区键跟主键/ 唯 一键解耦（MySQL 则要求pk/uk 必须包含分区键），分区锁支持将锁从表粒度降低到分区粒度显著增强并行能力。不过分区能力的增强仍旧不能避免大表下btree 局限问题。为此，PolarDB 又将btree 改成Blink-Tree （没有深入了解，简单说就是通过对节点添加额外字段实现tree 调整时全局加锁到部分加锁，进而提高并发度) 。同时对于大表DDL 问题，PolarDB 除支持instant ddl 能力外还通过并行DDL 能力充分利用存储I/O 能力加速DDL 进度。
即便有上述优化手段也不能彻底解决大表问题，笔者觉得（纯粹个人理解）基于上述优化后应该是比Aurora 裸大表的方式要好一些，起码会大程度上推迟性能瓶颈的到来，这又进一步了推迟了用户分库分表的紧迫性。
关于btree 访问的优化，笔者此前还了解到GreatSQL( 万里数据库) 将B+ 树划分为若干子树，通过多个线程并行扫描同一张InnoDB 表的不同部分，之后在将子线程结果汇总达到提升查询性能的目的，也是一个很机智的设计。
至于HTAP 能力，似乎PolarDB 有着更大的理想，其内置了X-Engine OLAP 分析引擎( 见下图)
这种一款数据库同时内置TP(btree&row 存e)+AP(lsm-tree& 列存) 两个引擎（两份数据），的方案，即数据通过日志的方式在各个引擎间同步，在近两年也逐渐涌现出来( 将离线ETL 过程给包了) ，可以想象其在成本、复杂度上该有多高，注定了专属于顶 级大厂的玩具，水平有限下文无法分解！
3、原生分布式
代表产品OceanBase 、TiDB ，该形态数据库通过天然的多副本设计+Paxos/Raft 分布式选举协议实现分布式。
在高可用、数据一致性上基于Paxos 协议实现，无需外部任何三方工具依赖数据具备强一致性，这一点跟存储计算分离实现高可用也略有不同。
在解决容量、性能问题上自不必说，OceanBase 同样具备良好的弹性扩展能力
容灾能力同样也比较灵活，能满足不同等级的容灾要求。
只需要添加节点即可完成容灾建设，操作过程也比较简单，当然其他形态的分布式数据库一样可以做到。
值得一提的是OceanBase 具备租户的概念，且租户间资源是隔离的，这一点是有别于目前市场上绝大部分分布式数据库的。基于租户这个特性能玩的花样就多了，如对绝大部分公司而言大部分DB 其实都不会面临容量、性能上的问题，这些小DB 又有存在的理由，通常我们还不能将它堆到一个集群里，因为无法解决隔离问题，这里多租户就派上用场了。
这里集群租户间资源共享还是隔离是可以灵活设置的，一般有cpu share （共享）、cpu set （独占）两种方式，可以基于场景设置，以实现业务的错峰部署，最大化提高资源利用率。同时，租户的出现可以让DBA 在提高资源利用率上具备更灵活的调度策略，如可以开发资源调度系统动态调配不同租户在不同时间的规格配置。这里资源隔离一定要是物理隔离的，如果租户是逻辑隔离意义就小很多。
OceanBase 采用了LSM Tree 的存储方式，为了避免写放大等性能问题，OceanBase 的理念也很简单：能通过硬件解决的问题都不是问题。这让我们看到了单OBServer 居然有恐怖的700G 内存，这足以容纳绝大部分业务12 小时的变更量了，因此，读写尽量在内存中完成，待到低峰期在悄悄完成Compaction 。其他都挺好的就是贵！^_^...... ，
不过在硬件越来越便宜的今天，以及OceanBase 4.0 开始小型化、单机化，使得OceanBase 也能飞入寻常百姓家了。
在大表的维护上，OceanBase 类似PolarDB 也是通过分区表的方式来解决，同样可以将分区分布到其他OBServer ，只是不清楚是否也做了PolarDB 在分区上的诸多优化。所以想当然的会认为OceanBase 也存在大表下性能问题和变更问题。不过，OceanBase 并不担心大表DDL 的问题，原因是得益于上述那个昂贵的设计（OceanBase 本身也是维护了schema version 的对于大部分DDL 同城都是online 的），通过低峰期发起Major freeze 操作合并完成DDL 自然也就完成了。同时为避免合并带来的影响，OceanBase 通过多个Zone 间轮转合并避免对用户造成影响。不过OceanBase2.0 开始在创建索引时就不用等到合并后生效了，用户创建索引就发起索引构建流程缩短生效时间。
关于OceanBase 兼容性，它同时兼容Oracle 跟MySQL 的。OceanBase 并不是像Aurora 那样接近原汁原味的MySQL Server 对MySQL 兼容，而是协议层的兼容( 小插曲：据说为了跟原汁原味的MySQL 表现一致就连Bug 都一起兼容了) 。从笔者当初使用OceanBase 的经验上看，对MySQL 的兼容度也比较完整，值得一提的是从MySQL 迁移到OceanBase 存储规模下降了2/3 。
关于HTAP 可以参考此前OceanBase CTO 的一篇相关文章《真正的HTAP对用户和开发者意味着什么》 ，引用里面的一个重要观点：
真正的 HTAP 系统有一个要求是基于”一份数据”同时做好交易和分析。那么，什么叫做“一份数据”？想要回答这个问题，核心是要回答哪一种做法是对用户最友好且性价比更高。我认为，数据的多个副本或者多种形态（列索引/ BTree 索引/ Bitmap 索引等）都可以被认为是”一份数据”，前提是能够在满足 HTAP 处理需求的前提下最大 程度降低数据冗余。例如，OceanBase 往往存储多个副本（ 3 个副本/ 5 个副本），可以选择让其中一个备副本专门做 OLAP 查询；Oracle IMC 支持对表格在内存中建立列索引，SQL Server 支持对表格在磁盘/内存中建立列索引，从用户的角度仍然是“一个系统，一份数据”。
从这里似乎可以窥探到OceanBase关于HTAP的一些设计思想点：一个系统，一份数据，多副本行列混合存，不搭积木。不过由于资料比较少也没有从OceanBase的架构上看到HTAP是怎么体现的，当然肯定有别于以PolarDB为代表的“多份数据”方案。多份数据实现上可能很复杂但OceanBase选择的道路似乎也并不简单甚至更复杂！
我们再从TiDB架构图上看（如下图），对比之下，OceanBase似乎更加简洁一点，起码组件没那么多（部署不够友好）不过这似乎也不是什么大的问题，况且TiDB提供了简洁的部署方案，不得不说TiDB真的很聪明特别懂用户心思，不管是对一个简单的部署，还是一开始选择基于MySQL协议去研发，又或者是围绕MySQL生态打造的各种工具等等都深得用户心意，这一点跟极力试图通过技术证明自己牛逼的产品，走的是不同路子。
对于性能、容量扩展性问题，TiDB 同样不逊色，其他分布式数据库也具备良好弹性能力，至于兼容性本身就是基于MySQL 协议打造且在一些互联网公司也都验证过了。当然在一些场合下会拿各个数据库进行性能比较，先不说比较的基准是否一致，性能肯定不是选型的第一考虑因素，毕竟性能是可以通过资源去弥补的，因此性能可扩展性非常重要，如最开始提到的：给够资源用不到那分布式就没有意义。稳定性应该更重要，这一点OceanBase 在自身大规模金融支付场景下得到过验证这一点是具备足够的说服力的。
关于HTAP ，TiDB 通过内置TiFlash 引擎来实现类似PolarDB 的X-Engine 做法跟OceanBase 的“ 一份数据” 理念似乎还是有点不一样的，太复杂看不清楚。也很难说谁优谁劣只能交给时间跟市场去检验了。
在TiDB6.0 里面有多租户概念、虽然也实现了物理隔离，跟OceanBase 基于内核虚拟化技术不同的是，TiDB 是通过资源打标+ 调度的方式来实现的，个人觉得OceanBase 在这方面要更胜一筹，分布式数据库下租户应该成为一种标配能力，一方面对私有云部署维护管理更加友好，另外对用户而言分布式就是一个无限大的单机数据库不用担心容量跟性能问题，且资源是隔离的。
使用了分布式就可以一劳永逸地解决性能、容量问题了？其实不然，该做的数据拆分跟业务架构改造还是要继续做的，主要还是取决于你的业务体量到底有多大。蚂蚁的交易支付系统体量足够大吧，也没有把所有数据都放到一套OceanBase 集群里啊，同样也是将业务拆分（蚂蚁的单元化架构）到多集群的（俗称百库百表）。当然这是个极端的例子，如果对一个百万订单的系统那兴许就不用了，或者更低一点的业务量还要啥分布式啊，单机数据库就挺好的。
对比总结
通过对三种形态的分布式数据库对比，针对可用性、一致性、容量、性能、维护、容灾、HTAP 的支持上做了一下简单总结，毕竟不管什么类型的数据库最终还是要回归到数据库的本质。需要说明的是下表 不具有选型倾向性，只是理念的不同带来风格的迥异并无高下之分！！！
|
|
数据库基本要求 | 使用友好性 | 扩展要求 | ||||||
|
|
可用性 | 一致性 | 扩展能力 | 容灾能力 | 业务侵入性 | 可维护性 | 普适性 | HTAP支持 | 租户 |
| 分布式中间件 | 中 | 弱一致性 | 复杂 | 弱 | 高侵入 | 简单 | 适合中小厂 | 无 | 无 |
| 存储计算分离 | 高 | 强一致性 | 简单 | 强 | 无侵入 | 复杂 | 大厂专属 | 弱 | 无 |
| 原生分布式 | 高 | 强一致性 | 简单 | 强 | 无侵入 | 复杂 | 大厂专属 | 弱 | OB更优 |
中间件方案是历史的产物也有它存在的道理，长期看一定会被淘汰，只是周期会比较久（可能分布式数据库云化能加速升级进度），短期内仍旧是中小互联网公司的首 选方案，毕竟相对简单一些。
也没有万 能的数据库，上面介绍的分布式数据库还是以解决OLTP 为主的，并不适合解决所有场景需求，比如json 、图、kv 、cache 、schemaless 、dt 等场景的需要还是要使用特定类型的数据库。
选型技术之外的考量因素
即使通过上述简单的对比，选择依据似乎还不够。还要从如下几个方面进行考虑。
1. 成熟度。
一款数据库成熟度怎么样可以从历史版本发布情况来简单分析，如果频繁的大版本发布及小版本修复各种致命bug 、缺陷等，显然不能被一般外部用户接受。以MySQL 为例，2005 年 MySQL 5.0 发布到今天MySQL 8.0 成熟经历了17 年，其中MySQL 8.0 从2016 年发布到今天一个版本的稳定打磨就经历了7 年！数据库注定是要十年磨一剑的。
2. 标杆应用。
在业内是否被大规模验证过了，或者有标志性的成功案例。很多国产数据库目前整体还是闭塞的虽然号称在金融、电信、银行、保险等领域上线了，但实际情况怎么样完全不得而知，尤其互联网公司崇尚的是开源这一类的数据库很难被接受。
3. 技术底蕴&靠山
所谓大厂出品必属精品，随便一个什么公司搞一个数据库是很难被接受的。大家普遍认可业内顶尖的一 流公司做背书的产品，甚至在深入了解一下开发这款数据库的团队靠谱吗？毕竟数据库的复杂度堪比操作系统，要求非常高，甚至团队规模怎么样，不要指望百十人的团队能写出靠谱的数据库（KPI 产品例外）。当然中间件方案的分布式例外，毕竟核心是做Proxy ，复杂度远不在一个数量级上。
4. 生态。
生态主要看技术、人才、文档、服务这四方面。
技术方面，业务接入的改造是否低成本，或者说是否能复用成熟的生态( 比如TiDB 和OceanBase 都是完整支持MySQL 协议的) ，是否足够开放让社区或者相关从业人员尽可能参与进来？比如TiDB 这方面做的就很好。周边生态工具是否齐全，比如业务研发高频使用的IDE 工具，DBA 更加关心的一些技术接口或者现成的实用运维工具等。
人才方面，市场是否有足够数量的从业人员如DBA 。
文档方面，此前国产数据库整体上文档完整性比较弱，现在好很多了，不过整体文档水平跟MySQL 这样的开文档比还有差距，很明显的感受是：告诉你怎么用，很少告诉你为什么或者原理性的东西比较少，可能是写文档的同学不是内核研发。
服务方面，国产数据库的诞生有现实的需求，但整体相比传统商业数据库成熟度还不够，因此需要更好的售后服务及支撑体系才能弥补整体的不足。分布式数据库未来上云是个大方向，毕竟对绝大部公司而言是很难有人力跟能力去驾驭一个复杂的、成熟度有待打磨的产品。
5. ROI
主要看引入分布式要解决什么问题，如果是成本，很不幸小范围引入分布式数据库可能成本会更高！毕竟相比单机数据库，分布式数据库普遍对硬件成本要求非常高，比如TiDB 和OceanBase 都有很高的硬件要求（OceanBase4.0 小型化后改观很多）。如果是性能优化那更不幸，通常benchmark 可能跑不过单机数据库！分布式数据库的整体收益只能在达到一定规模后才能发挥出成本、性能优势。因此，如果只是某个单一场景引入分布式来解决可能不是太好的选择。据说携程是做了大规模MySQ/Oracle 升级OceanBase ，相信他们应该有相关的数据可供参考。
关于ROI 可以简单的比喻：分布式是卡车，拉的多跑的慢，单机数据库是轿车拉的少跑的快，因此要有个平衡。最后引用一句话:“ 过早的优化是万恶之源” 。
6. 兼容性验证
虽然很多数据库都号称100 % 兼容MySQL 等协议，但还是要以自己的实际验证结果为准（99.99% 的兼容跟100 % 的兼容对结果的影响是巨大的）。起码你要有SQL 流量回放能力来验证执行计划跟执行效率的差异吧。此外，对于能否平滑迁移， 成熟的产品往往有一套完整的解决方案，要考虑上线后你真的能驾驭它吗。
最后的最后，也在最初的最初，我们要考虑的是：真的需要分布式数据库吗？