分库分表，可能真的要退出历史舞台了！

分库分表在当前阶段仍有其适用场景，并未完全退出历史舞台，但在未来可能逐渐被NewSQL数据库替代，尤其在互联网及高并发场景中优势减弱，传统行业核心系统仍可稳妥使用。 以下从多个方面进行详细分析：

• 存储与并发控制：传统数据库面向磁盘设计，基于内存的存储管理及并发控制效率不如NewSQL数据库。NewSQL数据库能更高效地利用内存资源，提升数据库性能。
• 避免重复工作：中间件模式存在SQL解析、执行计划优化等在中间件与数据库中重复工作的问题，效率较低。而NewSQL数据库避免了这种冗余低效的操作。
• 分布式事务性能：NewSQL数据库的分布式事务相比于XA进行了优化，性能更高。例如google percolator分布式事务模型，采用原子钟 + MVCC + Snapshot Isolation（SI），通过TSO保证了全局一致性，通过MVCC避免了锁，提高了性能。
• 高可用高可靠：新架构NewSQL数据库存储设计基于paxos（或Raft）协议的多副本，相比于传统数据库主从模式，实现了真正的高可用、高可靠（RTO < 30s，RPO = 0）。
• 自动化运维：NewSQL数据库天生支持数据分片，数据的迁移、扩容都是自动化的，大大减轻了DBA的工作，同时对应用透明，无需在SQL指定分库分表键。

• 分布式事务

  CAP限制：NewSQL数据库并未突破CAP定理限制，如Google Spanner宣称是一个“实际上是CA”的，原因是其打造私有全球网保证了不会出现网络中断引发的网络分区，以及高效的运维队伍。

  完备性：完备的分布式事务支持并非易事，需要应对网络以及各种硬件异常，目前已知的NewSQL在分布式事务支持上层次不齐。

  性能：虽然NewSQL数据库的分布式事务相比XA有所优化，但相比于1PC，2PC多出来的GID获取、网络开销、prepare日志持久化还是会带来很大的性能损失，尤其是在跨节点数量较多时。

  

• HA与异地多活

  网络延迟限制：很多NewSQL数据库厂商宣传基于paxos或raft协议可以实现异地多活，但实际上有前提，即异地之间网络延迟不能太高。以银行“两地三中心”为例，异地之间延时达到数十毫秒，高延时几乎没有OLTP系统可以接受。

  实现难度：分布式一致性算法在工程实践时，需要考虑很多异常并做很多优化，实现一个生产级可靠成熟的一致性协议并不容易。

• 分片机制：NewSQL数据库统一的内置分片策略可能并不是最高效的，因为与领域模型中的划分要素并不一致，这会导致很多交易产生分布式事务。例如银行核心业务系统以客户为维度，若按照各表主键range进行分片，高频OLTP系统中会产生性能问题。
• SQL支持：NewSQL数据库一般并不支持存储过程、视图、外键等功能，且SQL支持仅局限于兼容的MySQL或者PostgreSQL协议。
• 存储引擎：LSM的读由于需要合并数据性能比B + 树差，一般来说LSM更适合应用在写大于读的场景。NewSQL数据由于多副本、分布式事务等开销，相比单机关系数据库SQL的响应时间并不占优。
• 成熟度与生态：NewSQL数据库多集中在互联网以及传统企业非核心交易系统中，目前还处于快速迭代、规模使用不断优化完善的阶段。相比而言，传统关系数据库在成熟度、功能、性能、周边生态、风险把控、相关人才积累等多方面都具有明显优势，同时对已建系统的兼容性也更好。

• 优势：分库分表是一个上限低但下限高的方案，架构简单，技术门槛更低。对于大多数OLTP场景，其最核心的诉求是拆分后SQL的正确路由，中间件模式应对绰绰有余。
• 适用场景：尤其适用于传统行业的核心系统，如果仍然打算把数据库当做一个黑盒产品来用，踏踏实实用好分库分表是个稳妥的选择。例如银行这种风险意识较高的行业，在未来一段时间内可能仍处于对NewSQL数据库探索、审慎试点的阶段，分库分表模式在大多数场景下仍可满足需求。