NewSQL vs Sharding: Which Database Architecture Truly Wins?

NewSQL数据库先进在哪儿？

本文通过对两种模式关键特性实现原理的对比，客观阐述 NewSQL 与中间件+分库分表的优缺点以及适用场景。

根据国外论文的分类，Spanner、TiDB、OceanBase 属于第一类新架构型，Sharding‑Sphere、Mycat、DRDS 等中间件方案属于第二类。

中间件+关系数据库的分库分表模式在存储上已实现分布式，但在 SQL 解析、执行计划生成以及存储引擎上存在冗余，因而被称为“伪”分布式。

NewSQL 相比中间件的优势

传统数据库面向磁盘设计，基于内存的存储管理及并发控制不如 NewSQL 高效。

中间件层重复进行 SQL 解析和执行计划优化，效率低下。

NewSQL 的分布式事务在 XA 基础上进行了优化，性能更高。

NewSQL 采用基于 Paxos 或 Raft 的多副本存储，实现真正的高可用和低 RTO/RPO。

NewSQL 天生支持自动分片、迁移和扩容，降低 DBA 工作量且对应用透明。

分布式事务与 CAP 限制

分布式事务是一把双刃剑，CAP 定理仍然约束系统在强一致性、可用性和分区容忍性之间的取舍。NewSQL 如 Google Spanner 通过私有网络降低分区概率，实现近似 CA 状态。

分布式系统中，您可以知道工作在哪里，或者您可以知道工作何时完成，但无法同时了解两者；两阶段协议本质上是反可用性协议。

HA 与异地多活

基于 Paxos/Raft 的多副本方案是业界主流，Google Spanner、TiDB、CockroachDB、OceanBase 均采用此方式，实现自动选主和快速故障恢复。但异地多活受网络延迟限制，跨地域的强一致性仍具挑战。

Scale 横向扩展与分片机制

NewSQL 内置分片机制，可自动识别热点并进行分片拆分、迁移和合并，例如 TiDB 将数据切成 region 并在达到阈值时自动迁移。

分库分表模式也能做到在线扩容，基本思路是通过异步复制先追加数据，然后设置只读完成路由切换，最后放开写操作。

分布式 SQL 支持

NewSQL 支持跨分片的 JOIN、聚合等复杂 SQL，采用基于统计信息的成本优化器（CBO），而中间件模式多使用规则优化（RBO），对跨库 JOIN 支持有限。

存储引擎对比

传统关系数据库多基于 B+Tree，适合磁盘读写；NewSQL 多采用 LSM，将随机写转为顺序写，提高写入性能，尽管读性能略有下降，但通过 SSD、Bloom Filter 等技术可得到优化。

成熟度与生态

NewSQL 仍在快速迭代阶段，生态和工具相对传统关系数据库不够成熟；传统数据库经过多年发展，在功能、性能、社区和 DBA 人才方面更具优势。

总结与选型指南

如果以下问题中有两到三项肯定——强一致事务必须在数据库层解决、数据增长不可预估、扩容频率超出运维能力、更看重吞吐而非响应时间、需要对应用完全透明、拥有熟悉 NewSQL 的 DBA 团队——则可考虑 NewSQL。否则，分库分表配合中间件是成本更低、风险更小的稳妥方案。