NewSQL 分布式数据库——规模化关系型数据 / Distributed SQL for Relational Data at Scale
📅 创建时间：2026-05-08 🏷️ 标签：#NewSQL #TiDB #CockroachDB #OceanBase #分布式SQL #水平扩展 📚 前置知识：[[00-db-overview]] [[01-mysql]] [[02-postgresql]]（理解 ACID 和扩展需求） 📚 相关知识：[[08-vector-database]]（向量扩展）、[[17-lobechat-design-analysis]]（LobeChat 的数据库选型）
定位速览
┌─────────────────────────────────────────────────────────────┐
│ NewSQL 在数据库版图中的位置 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 问题：MySQL 单机扩展到瓶颈怎么办？ │
│ │
│ 传统方案：分库分表（ShardingSphere） │
│ → 解决了数据量问题，但 JOIN 跨节点困难，业务代码入侵大 │
│ │
│ NewSQL 方案： │
│ → 保留 SQL 和 ACID 事务 │
│ → 自动水平扩展（像 NoSQL 一样简单） │
│ → 对应用透明（不用改 SQL，不用改代码） │
│ │
│ 代表产品：TiDB / CockroachDB / OceanBase │
│ │
└─────────────────────────────────────────────────────────────┘第1部分：为什么需要 NewSQL
1.1 MySQL 的扩展瓶颈
┌─────────────────────────────────────────────────────────────┐
│ MySQL 的扩展瓶颈 vs NewSQL 的解决思路 │
├─────────────────────────────────────────────────────────────┤
│ │
│ MySQL 单机瓶颈： │
│ │
│ 垂直扩展 → 机器总有极限（CPU/内存/磁盘） │
│ 读写分离 → 写入是瓶颈（只有一台 Master） │
│ 分库分表 → 应用需要知道数据在哪台机器 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 分库分表的问题： │ │
│ │ │ │
│ │ SELECT * FROM orders WHERE user_id = ? │ │
│ │ -- 需要知道 user_id 在哪个分片 │ │
│ │ │ │
│ │ SELECT COUNT(*) FROM orders GROUP BY status │ │
│ │ -- 需要跨 4 个分片 聚合，再合并结果 │ │
│ │ │ │
│ │ SELECT u.name, o.total │ │
│ │ FROM users u JOIN orders o ON u.id = o.user_id │ │
│ │ -- users 和 orders 在不同分片？JOIN 失效 │ │
│ │ │ │
│ │ 应用层被迫感知分片逻辑，SQL 表达能力大幅受限 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ NewSQL 的解决思路： │
│ → 分布式 SQL 引擎：把 JOIN/聚合 下推到存储层 │
│ → 自动分片 + 自动路由：应用像用单机数据库一样 │
│ → 自动数据均衡：加节点，数据自动重新分布 │
│ │
└─────────────────────────────────────────────────────────────┘1.2 NewSQL 的核心承诺
┌─────────────────────────────────────────────────────────────┐
│ NewSQL 的核心承诺 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. SQL 完整性：标准 SQL，无语法限制 │
│ 2. ACID 事务：强一致性，支持跨节点事务 │
│ 3. 水平扩展：加节点即扩展，数据自动均衡 │
│ 4. 高可用：单节点故障不影响服务（Raft 共识） │
│ │
│ 与 NoSQL 的区别： │
│ • NoSQL（MongoDB / Cassandra）放弃部分 SQL 能力 │
│ • NewSQL 保留完整 SQL + ACID，但通常牺牲部分性能 │
│ │
│ 与分库分表的区别： │
│ • 分库分表：应用需要分片感知 │
│ • NewSQL：对应用完全透明，像单机数据库一样使用 │
│ │
└─────────────────────────────────────────────────────────────┘第2部分：TiDB——MySQL 兼容的分布式数据库
2.1 架构
┌─────────────────────────────────────────────────────────────┐
│ TiDB 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ TiDB Server（SQL 层） │ │
│ │ • 解析 SQL │ │
│ │ • 生成执行计划 │ │
│ │ • 分布式查询协调 │ │
│ │ • MySQL 协议兼容（PD / MySQL 客户端直连） │ │
│ └───────────────────────┬────────────────────────────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ TiKV 1 │ │ TiKV 2 │ │ TiKV 3 │ │
│ │ (存储节点) │ │ (存储节点) │ │ (存储节点) │ │
│ │ │ │ │ │ │ │
│ │ Region 1 │ │ Region 2 │ │ Region 3 │ │
│ │ (Raft Grp) │ │ (Raft Grp) │ │ (Raft Grp) │ │
│ │ [0-10K) │ │ [10K-20K) │ │ [20K-30K) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ ↕副本（3份） ↕副本 ↕副本 │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Placement Driver（PD，元数据调度器） │ │
│ │ • 管理 Region 分布 │ │
│ │ • 生成全局时间戳 │ │
│ │ • 调度数据均衡（热点检测） │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ TiFlash（可选列式副本）： │
│ • 同一数据同时有行式（TiKV）和列式（TiFlash）副本 │
│ • OLTP 用行式，OLAP 用列式，一份数据两种用途 │
│ │
└─────────────────────────────────────────────────────────────┘2.2 核心概念
┌─────────────────────────────────────────────────────────────┐
│ TiDB 核心概念 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Region（数据分片）： │
│ • TiKV 将数据分成多个 Region（默认 96MB） │
│ • 每个 Region 有 3 副本（3 台不同 TiKV 节点） │
│ • 副本之间用 Raft 协议保持一致 │
│ • PD 自动调度 Region 分布（热点分裂、负载均衡） │
│ │
│ 乐观事务 vs 悲观事务： │
│ • 乐观事务：事务提交时才检测冲突（适合少冲突场景） │
│ • 悲观事务：事务开始时就加锁（适合多冲突场景，MySQL 风格）│
│ • 配置：set @@tidb_txn_mode = 'pessimistic' │
│ │
│ MySQL 兼容性： │
│ • 兼容 MySQL 5.7 协议 │
│ • 大部分 MySQL 语法可直接迁移 │
│ • 迁移工具：TiDB DM（Data Migration） │
│ │
└─────────────────────────────────────────────────────────────┘2.3 TiDB 实战
sql
-- 1. 基本操作（与 MySQL 完全相同）
SELECT * FROM users WHERE id = 1;
INSERT INTO orders (user_id, total) VALUES (1, 100.50);
UPDATE users SET last_login = NOW() WHERE id = 1;
DELETE FROM sessions WHERE expired_at < NOW();
-- 2. 查看执行计划（分布式 EXPLAIN）
EXPLAIN SELECT u.name, COUNT(o.id) as order_count
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.created_at > '2026-01-01'
GROUP BY u.id, u.name;
-- TiDB EXPLAIN 输出包含：
-- • tableScan / indexScan：扫描类型
-- • Selection：过滤条件
-- • Aggregation：聚合下推到了 TiKV
-- • ExchangeReceiver：结果汇总回 TiDB Server
-- 3. 悲观事务（适合高并发写入）
BEGIN PESSIMISTIC;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE; -- 行锁
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
-- 4. 设置会话变量
SET SESSION tidb_hash_join_concurrency = 4;
SET SESSION tidb_distsql_scan_concurrency = 15;
-- 5. 查看集群状态
SHOW TABLE REGIONS WHERE Table = 'orders';
-- 查看某个表的 Region 分布情况
SHOW CONFIG WHERE TYPE = 'tikv' AND NAME LIKE '%region-split%';第3部分：CockroachDB——PostgreSQL 兼容的全球数据库
3.1 架构
┌─────────────────────────────────────────────────────────────┐
│ CockroachDB 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 设计哲学："像使用一个无限大单机数据库" │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 单一地址入口（任何节点） │ │
│ │ postgres://user:pass@any-node:26257/db │ │
│ └───────────────────────┬────────────────────────────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Node 1 │ │ Node 2 │ │ Node 3 │ │
│ │ (美东) │ │ (美西) │ │ (欧洲) │ │
│ │ │ │ │ │ │ │
│ │ SQL Layer │ │ SQL Layer │ │ SQL Layer │ │
│ │ KV Layer │ │ KV Layer │ │ KV Layer │ │
│ │ Storage │ │ Storage │ │ Storage │ │
│ │ (Pebble) │ │ (Pebble) │ │ (Pebble) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ ↕副本（Raft） ↕副本 ↕副本 │
│ │
│ 特点： │
│ • 每个节点同时是 SQL 层 + 存储层（无分离） │
│ • 任意节点可接收 SQL 请求（自动路由） │
│ • 全局强一致（即使跨地域） │
│ • PostgreSQL wire 协议兼容（psql 直连） │
│ • License: 2024 年改为 Enterprise License │
│ │
└─────────────────────────────────────────────────────────────┘3.2 全球分布与一致性
sql
-- CockroachDB 全球分布能力
-- 副本可配置在不同地域，实现强一致 + 低延迟
-- 区域配置（Region）
ALTER DATABASE app SET REGION = 'us-east';
ALTER TABLE users ADD REGION = 'us-east';
ALTER TABLE orders ADD REGION = 'us-east';
ALTER TABLE products ADD REGION = 'us-central';
-- 就近写入（自动路由到最近节点）
-- 用户在美东 → 写入美东节点 → 同步到其他节点
-- _follower_reads：读附近副本（低延迟，弱一致）
SET TRANSACTION AS OF SYSTEM TIME '-5s'; -- 5 秒前的数据（可读副本站点）
SELECT * FROM products WHERE id = 1;
-- 查看数据分布
SHOW EXPERIMENTAL LOCATIONS;
SELECT region, replicas FROM [SHOW RANGES FROM TABLE users];
-- 冲突处理（与 PostgreSQL 相同的 MVCC）
INSERT INTO accounts (id, balance) VALUES (1, 1000)
ON CONFLICT (id) DO UPDATE SET balance = accounts.balance + 100;第4部分：OceanBase——金融级国产分布式数据库
┌─────────────────────────────────────────────────────────────┐
│ OceanBase 核心定位 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 支付宝出品，支撑双十一（全球最高 TPS 的交易系统） │
│ 核心优势： │
│ • 金融级可靠性（RPO=0，3 副本 Paxos） │
│ • 超大规模（单表 1000 亿行级别） │
│ • HTAP 能力（OLTP + OLAP 一体化） │
│ • 国产化替代（对标 Oracle/MySQL） │
│ │
│ 架构特点： │
│ • 混合行式/列式存储（同 TiFlash 理念） │
│ • OBProxy（SQL 路由代理，确保请求到正确 Zone） │
│ • 支持 MySQL 协议和 Oracle 协议 │
│ │
│ 性能数据（公开测试）： │
│ • 3.2 亿 tpmC（OLTP 世界纪录） │
│ • 单库 500 亿行 + 100TB 级别 │
│ │
└─────────────────────────────────────────────────────────────┘第5部分：三强横向对比
┌─────────────────────────────────────────────────────────────┐
│ TiDB vs CockroachDB vs OceanBase 横向对比 │
├─────────────────────────────────────────────────────────────┤
│ │
│ │ 维度 │ TiDB │ CockroachDB │ OceanBase│
│ ├──────────────┼───────────────────┼──────────────┼─────────┤
│ │ SQL 兼容 │ MySQL 5.7 │ PostgreSQL │ MySQL/ │
│ │ │ │ wire 协议 │ Oracle │
│ ├──────────────┼───────────────────┼──────────────┼─────────┤
│ │ 架构 │ 计算/存储分离 │ 统一节点 │ 计算/存储│
│ │ │ (TiDB/TiKV/PD) │ │ 分离 │
│ ├──────────────┼───────────────────┼──────────────┼─────────┤
│ │ 共识协议 │ Raft │ Raft │ Paxos │
│ ├──────────────┼───────────────────┼──────────────┼─────────┤
│ │ 存储引擎 │ TiKV (RocksDB) │ Pebble (Go) │ 自研 │
│ ├──────────────┼───────────────────┼──────────────┼─────────┤
│ │ HTAP │ TiFlash（列式副本）│ 无 │ 内置列式│
│ ├──────────────┼───────────────────┼──────────────┼─────────┤
│ │ License │ Apache 2.0 │ Enterprise │ 商业/ │
│ │ │ │ (2024) │ 社区版 │
│ ├──────────────┼───────────────────┼──────────────┼─────────┤
│ │ 规模案例 │ 字节/小米/ │ 亚马逊/ │ 支付宝/ │
│ │ │ Shopee │ 甲骨文Cockroach│ 滴滴 │
│ ├──────────────┼───────────────────┼──────────────┼─────────┤
│ │ 适合场景 │ MySQL 迁移 │ PostgreSQL │ 金融核心│
│ │ │ + OLAP 分析 │ 迁移+全球分布│ 系统+ │
│ │ │ │ │ 超大规模│
│ │
│ 选型建议： │
│ • 已有 MySQL → 想水平扩展 → TiDB（MySQL 兼容最好） │
│ • 已有 PostgreSQL → 想水平扩展 → CockroachDB（PG 兼容） │
│ • 金融核心系统 + 超大规模 → OceanBase │
│ • 想避免商业 License → TiDB（Apache 2.0） │
│ │
└─────────────────────────────────────────────────────────────┘第6部分：什么时候用 NewSQL vs 分库分表
┌─────────────────────────────────────────────────────────────┐
│ NewSQL vs 分库分表 决策指南 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 选择分库分表（ShardingSphere / MyCAT）的场景： │
│ ✅ 团队熟悉 MySQL，不想学新技术 │
│ ✅ 已有 MySQL 分库分表基础设施 │
│ ✅ 业务表结构清晰，分片键选择容易 │
│ ✅ 不需要跨分片 JOIN（大部分 JOIN 在单表内完成） │
│ ✅ 成本敏感，不想引入 NewSQL 集群 │
│ │
│ 选择 NewSQL 的场景： │
│ ✅ 需要跨节点 JOIN / 聚合（不想被分片逻辑限制） │
│ ✅ 需要强一致事务（跨表/跨节点） │
│ ✅ 不想改应用代码（透明水平扩展） │
│ ✅ 需要全局唯一 ID / 序列（NewSQL 内置生成） │
│ ✅ OLTP + OLAP 混合负载（TiDB + TiFlash） │
│ ✅ 需要高可用（NewSQL 内置 failover） │
│ │
│ 实战经验： │
│ • 80% 的 MySQL 应用分库分表就够了 │
│ • 当分库分表的复杂度超过 NewSQL 学习成本时，迁移到 NewSQL │
│ • NewSQL 的运维复杂度比想象中更高（分布式调试更难） │
│ │
└─────────────────────────────────────────────────────────────┘学习状态：🟡 开始学习