NewSQL 工作原理
本篇着重介绍 Aurora、PolarDB、TiDB、OceanBase 这几类 NewSQL 或新架构关系型数据库的设计思想。它们的共同目标，是在保留 SQL 和事务能力的同时，尽量获得更好的弹性、高可用和水平扩展能力。
NewSQL 不是一种单一架构，而是一组工程方向：有的选择计算存储分离，有的选择共享存储，有的选择 shared-nothing 分布式事务，有的强调兼容 MySQL，有的强调跨地域一致性。理解这些差异，比简单比较“谁性能更好”更有意义。
NewSQL 想解决的问题
传统单机关系型数据库在中小规模 OLTP 场景下非常稳定，但当业务增长到一定规模后，会遇到几个典型瓶颈：
- 容量瓶颈：单机磁盘、内存、IOPS 有上限。
- 可用性瓶颈：主从切换、复制延迟、故障恢复会影响业务连续性。
- 扩展瓶颈：垂直扩容成本高，分库分表又会把复杂度推给应用。
- 事务瓶颈：应用层分片后，跨分片事务、全局唯一约束和复杂查询会变难。
NoSQL 通过牺牲部分事务语义换取扩展性，而 NewSQL 希望把 SQL、ACID 和扩展性重新组合起来。代价是数据库内部需要引入分布式一致性协议、全局时间戳、分布式调度、复制协议和更复杂的故障恢复机制。
计算存储分离
Aurora 和 PolarDB 都可以放在“计算存储分离”的方向下理解。传统 MySQL 中，计算节点和存储引擎紧密绑定，数据页、redo log、Buffer Pool、复制关系都围绕单机实例展开。计算存储分离则把数据库拆成两层：
- 计算层：负责 SQL 解析、优化、执行、事务协调和连接管理。
- 存储层：负责数据持久化、多副本复制、故障恢复和高可用。
这样做的核心收益是把故障域和扩展方式拆开。计算节点可以更快地重启或替换，存储层独立维护多副本，读节点也可以更方便地扩展。
Aurora 的设计思想
Aurora 的经典设计是兼容 MySQL/PostgreSQL 协议，同时重写底层存储架构。它把传统数据库中大量由计算节点完成的日志复制、恢复和存储容错能力下沉到分布式存储层。
传统 MySQL 主从复制通常复制逻辑 binlog 或物理变更，并且每个副本都维护一份相对完整的数据库实例。Aurora 的思路是让计算节点把 redo 日志发送到存储层，由存储层负责多副本持久化和恢复。它常被概括为“复制日志，而不是复制数据页”。
这种设计有几个好处：
- 写入路径更轻，计算节点不需要把完整数据页同步给多个副本。
- 存储层可以跨多个可用区维护副本，提高故障容忍能力。
- 崩溃恢复可以由存储层并行完成，减少实例恢复时间。
- 读副本共享同一套底层存储，减少传统复制链路中的数据冗余和延迟。
但 Aurora 也不是没有代价。它深度依赖云厂商的存储和网络基础设施，用户获得了更好的托管能力，也把底层控制权交给了云平台。对于强依赖云生态、希望减少自建运维复杂度的系统，这是合理选择；对于需要跨云、私有化或深度定制存储层的系统，则要谨慎评估。
PolarDB 的设计思想
PolarDB 和 Aurora 类似，也强调计算存储分离和云原生数据库架构。它通常通过一个主计算节点和多个只读计算节点共享底层分布式存储来提供服务，底层存储负责数据多副本和高可用。
这种架构适合读多写少、需要弹性扩展读能力的业务。只读节点不需要像传统主从复制那样完整复制一份数据，而是共享存储层的数据，理论上可以降低复制延迟和存储成本。
需要注意的是，共享存储并不意味着所有问题都消失了：
- 写入仍然需要由主节点或写入协调者处理，写扩展能力不是无限的。
- 只读节点读取最新数据时，仍然需要处理缓存一致性和日志可见性。
- 复杂查询、热点行更新、大事务等问题仍然会回到数据库执行层。
所以 PolarDB 这类数据库更适合把“单机 MySQL 的容量、可用性和读扩展问题”向后推，而不是把应用直接变成无限水平扩展的系统。
Shared-Nothing 分布式数据库
TiDB、OceanBase 更接近 shared-nothing 分布式数据库方向。所谓 shared-nothing，是指每个节点都有自己的 CPU、内存和存储，节点之间通过网络协作，不共享本地磁盘。
这种架构的核心是把数据切成很多分片，再通过一致性协议维护每个分片的多个副本。系统需要解决几个关键问题：
- 数据如何自动分片和迁移。
- 每个分片的副本如何选主和复制。
- 跨分片事务如何提交或回滚。
- 全局时间戳如何生成。
- SQL 优化器如何把查询下推到数据所在节点。
- 节点故障、扩容、缩容时如何保持一致性。
相比计算存储分离，shared-nothing 架构更强调水平扩展能力，但也引入了更多分布式系统复杂度。单条本地事务会变成跨节点通信，网络延迟、热点分片、调度策略都会影响性能。
TiDB 的设计思想
TiDB 的整体架构可以粗略分为三层：
- TiDB Server：无状态 SQL 层，负责协议兼容、SQL 解析、优化和执行。
- PD：集群元信息和调度中心，负责时间戳、Region 调度和集群控制。
- TiKV：分布式 KV 存储层，数据按 Region 切分，并通过 Raft 复制。
TiDB 的一个重要思想是把 SQL 层做成无状态，把有状态的数据切分到 TiKV 中。SQL 层可以水平扩展，存储层通过 Region 自动分裂、迁移和复制。事务层通过全局时间戳和 MVCC 来提供一致性视图，并通过两阶段提交完成跨 Region 事务。
这类架构适合数据规模较大、希望保留 MySQL 使用习惯，同时又不希望在应用层维护复杂分库分表逻辑的场景。它的代价是单条事务的链路更长，性能高度依赖 SQL 是否能下推、Region 是否均衡、热点是否被打散。
OceanBase 的设计思想
OceanBase 也是面向分布式 OLTP 的数据库，强调强一致、高可用和横向扩展。它通常以分区为基本数据组织单位，通过多副本复制协议保证数据可靠性，并在 SQL 层提供关系型数据库能力。
OceanBase 的工程重点在于把传统关系型数据库能力和分布式系统能力结合起来：
- 数据按分区分布到不同节点。
- 分区副本通过一致性协议复制。
- SQL 层需要处理分布式执行计划。
- 事务层需要协调跨分区提交。
- 多租户能力用于在同一集群内隔离资源。
这类数据库适合核心交易、金融级高可用、超大规模数据量等场景。但越是强大的系统，对团队的容量规划、SQL 治理、运维监控和故障演练要求越高。
NewSQL 的取舍
NewSQL 解决了很多传统数据库和分库分表的痛点，但它并不是银弹。选型时需要重点看以下问题：
- 业务是否真的需要强一致分布式事务。
- 数据规模是否已经超过单机数据库和合理分库分表的承载范围。
- SQL 是否以简单 OLTP 为主，还是有大量复杂关联、聚合和分析查询。
- 团队是否具备分布式数据库的运维、诊断和容量规划能力。
- 是否接受对云厂商或特定数据库生态的绑定。
- 迁移成本、回滚方案、数据校验和双写切换是否可控。
很多时候，单机 MySQL 加合理索引、读写分离、缓存、归档、异步化，已经能覆盖相当长一段业务生命周期。只有当业务确实碰到容量、可用性或跨分片事务问题时，再引入 NewSQL 才更稳妥。
建模上的影响
使用 NewSQL 并不意味着可以忽略建模。相反，分布式数据库会放大不良建模带来的问题：
- 热点主键会导致单个分片压力过高。
- 大事务会跨越更多节点，提交成本更高。
- 缺少索引会造成跨分片扫描，网络和 CPU 成本都会上升。
- 强一致读会比本地快照读更昂贵。
- 跨地域部署下，事务延迟会受到物理距离限制。
因此 NewSQL 场景下仍然需要遵循几个原则：
- 让高频事务尽量落在少量分片内。
- 避免无边界的大范围更新和删除。
- 设计能够打散热点的主键或分片键。
- 明确哪些查询需要强一致，哪些可以接受最终一致或异步视图。
- 把分析型查询和交易型查询拆开治理。
NewSQL 的价值不是让开发者不用思考数据模型，而是让数据库承担更多分布式一致性和弹性能力。越强的抽象越需要理解边界，只有知道底层大致如何工作，才能在业务建模时做出合适的取舍。