OceanBase与MySQL的比较
1、 OB的redo log是使用分布式一致性算法paxos实现的。所以在CAP理论中，虽然OB使用的是强一致模型，但是OB能在一定网络分区的情况下做到高可用（通俗点讲就是多余半数机器还活着的时候就能干活），官方的MySQL目前做不到这一点。
2、OB的存储结构使用的是两级的LSM tree。其中内存中的C0 Btree叶节点不需要和磁盘上的btree一样大小，所以能做得比较小，对CPU的Cache比较友好，并且不会有写入放大的问题。使得OB的写性能有极大的提升。同时磁盘上的C1 tree不是一个传统意义上的Btree（Btree未经压缩可能浪费一半空间）。空间利用率大大提高。简单来说就是速度快，省成本。
3、 数据库自动分片功能（支持hash/range，一级二级等等分片方式），提供独立的proxy路由写入查询等操作到对应的分片。这意味着数据量再大也不需要手动分库分表了。并且分片能在线的在各个server之间迁移，解决热点问题（资源分配不均的问题，做到弹性加机器和减机器）。每个分片（确切的说是被选为主的分片）都支持读写，做到多点写入（高吞吐量，性能可线性扩展）。
4、数据库内部实现的无阻塞的两阶段提交（跨机事务）。
5、数据库原生的多租户支持，能直接隔离租户之间的cpu、mem、io等资源。
6、高可用，对OceanBase而言，同一数据保存在多台（>=3）台服务器中的半数以上服务器上（例如3台中的2台），每一笔写事务也必须到达半数以上服务器才生效，因此当少数服务器故障时不会有任何数据丢失，能够做到RPO等于零。不仅如此，OceanBase底层实现的Paxos高可用协议，在主库故障后，剩余的服务器会很快自动选举出新的主库，实现自动切换，并继续提供服务，在实际的生产系统中做到RTO在20秒之内。
7、扩展能力。MySQL在数据库中间件的帮助下，可以通过分库分表来实现水平扩展。这种方案解决了传统数据库需要垂直扩展的通病，但还是存在相当的局限性，比如扩容和缩容困难、无法支持全局索引，数据一致性难以保证等。OceanBase则从数据库层面提供了真正意义上的水平扩展能力。OceanBase基于分布式系统实现，可以很方便地进行扩容和缩容，且能做到用户无感知。同时，OceanBase所具备的集群内动态负载均衡、多机分布式查询、全局索引的能力更进一步加强了其可扩展性。对于用户的分库分表方案，OceanBase提供了分区表和二级分区的功能，可以完全取而代之。
原文链接：https://blog.csdn.net/fuzhongmin05/article/details/118196626
