NewSQL 的定位
NewSQL 用共识协议把单机数据库的强一致能力扩展到多节点：SQL 接口、事务语义、水平扩展三者兼得，代表产品有 TiDB、OceanBase、CockroachDB、YugabyteDB，部分还带列存副本支撑 HTAP。它解决的是「单机容量或写入到瓶颈，但业务又离不开 SQL 与事务」这一类问题，代价是跨节点写入延迟高于单机。
基本信息
| TiDB | SQL 层 + TiKV 分布式 KV（Raft）+ PD 调度，TiFlash 提供列存副本 |
|---|---|
| CockroachDB | 按 Range 分片 + Raft 复制，默认隔离级别偏严格 |
| OceanBase | 多副本共识协议，兼顾事务与部分分析负载 |
| 共同点 | SQL 与事务语义 + 多节点扩展，跨节点写入延迟高于单机 |
| 适用前提 | 单机容量、写入吞吐或可用性已成为瓶颈，且团队具备分布式运维能力 |
| 迁移关注 | SQL 方言、事务语义、自增与热点键设计、延迟特征 |
典型使用场景
- 单机库容量触顶：分库分表改造成本高时评估分布式 SQL
- 写入吞吐瓶颈：需要横向扩展写能力且仍要事务
- HTAP 需求：同一份数据既要事务写入又要分析查询
- 高可用要求：多副本共识协议提供自动故障切换
- 平滑迁移：借助兼容性把现有业务逐步切到新集群
兼容性与执行计划核对（以 TiDB 为例）
兼容性与执行计划核对（以 TiDB 为例）
-- 先确认版本，再核对特性开关
SELECT VERSION();
-- SHOW VARIABLES LIKE 'tidb_enable_foreign_key';
-- 关键查询看执行计划，确认算子是否下推到存储层
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42;
-- 自增与热点：顺序主键在高并发插入时会集中到同一分片
-- 评估改用打散策略（如业务侧生成有序但分散的键）
-- SHOW CREATE TABLE orders;迁移评估项
| 评估项 | 关注点 | 验证方式 |
|---|---|---|
| SQL 方言 | 函数、窗口、存储过程与隐式类型转换差异 | 把业务 SQL 全量跑一遍对比结果 |
| 事务语义 | 隔离级别与锁行为不同会影响并发逻辑 | 用并发用例验证计数与库存逻辑 |
| 自增与主键 | 顺序键导致热点集中 | 压测观察分片压力分布 |
| 延迟特征 | 跨节点写入延迟高于单机 | 按真实拓扑压测 p99 延迟 |
| 运维能力 | 备份恢复、扩缩容、故障处理流程 | 演练一次扩容与恢复流程 |
迁移看三件事：SQL 方言差异、事务与主键语义、跨节点延迟对热点写入的影响。先小流量灰度验证，再考虑替换主库，别用一次性切换的方式上线。
分布式数据库的强一致读需要多数派确认：跨机房部署时写延迟取决于网络往返，拓扑设计要比单机时代更谨慎。