摘要
TiDB 与 AWS Aurora 分别代表了分布式数据库与云原生共享存储数据库两条技术路线。本文从架构设计、多可用区部署、扩展方式、成本模型和数据主权五个维度进行系统对比，帮助技术决策者在选型时做出更有依据的判断。
本文适合谁：正在评估云原生数据库选型的架构师、DBA、技术负责人，以及在多云策略和单云锁定之间权衡的团队。
1. 架构设计对比
| 维度 | TiDB | AWS Aurora |
|---|---|---|
| 架构类型 | 分布式计算-存储分离 | 共享存储 + 多副本计算 |
| 存储引擎 | TiKV（Raft 多副本）、TiFlash（列存） | Aurora 存储卷（6 副本跨 3 AZ） |
| 计算层 | TiDB Server（无状态多节点） | 读写分离（1 主 + 15 只读副本） |
| 协议兼容 | MySQL / PostgreSQL | MySQL / PostgreSQL |
| 事务模型 | Percolator / 2PC 分布式事务 | 单节点事务（存储层保证一致性） |
| 数据分片 | Range 分片，自动分裂/合并 | 无分片（单卷逻辑） |
TiDB 采用经典的计算-存储分离架构，计算节点（TiDB Server）无状态化，存储节点（TiKV）通过 Raft 协议在多节点间维护数据副本。这种设计天然支持水平扩展，每个组件可独立扩缩容。
Aurora 将存储与计算分离，但存储层是一个跨多可用区的分布式卷（6 副本），计算层通过主从复制实现读写分离。其核心创新在于将日志即数据库的理念落地，计算节点只需将 redo log 推送到存储层，避免了传统数据库的双写问题。
-- TiDB：查看集群拓扑
SELECT * FROM information_schema.tikv_store_status;
-- Aurora：查看实例拓扑（通过 RDS API 或 SQL）
SELECT server_id, @@hostname, @@port;
SHOW VARIABLES LIKE 'aurora_version';
2. 多可用区部署对比
TiDB 多可用区部署
TiDB 原生支持跨可用区部署，通过 Placement Rules 精细控制数据的副本分布策略：
-- TiDB Placement Rules：指定跨 3 个 AZ 的副本分布
CREATE PLACEMENT POLICY `3az-policy`
LEADER_CONSTRAINTS='[+zone=az1]'
FOLLOWER_CONSTRAINTS='[+zone=az2],[+zone=az3]'
LEADER_NUM_VOTERS=1
FOLLOWER_NUM_VOTERS=2;
ALTER TABLE orders PLACEMENT POLICY `3az-policy`;
- Raft Leader 可在不同 AZ 间自动切换
- 支持自定义副本数量（默认 3 副本）和 AZ 亲和性
- 可为不同业务表设置不同的放置策略
- 跨区域部署支持（TiCDC + DR 方案）
Aurora 多可用区部署
Aurora 的多 AZ 能力内置于存储卷设计：
Aurora Storage Volume (6 副本)
├── AZ-1: 2 副本（其中 1 个为 Learner）
├── AZ-2: 2 副本
└── AZ-3: 2 副本
- 存储层自动在 3 个 AZ 间分布 6 个副本
- 计算层支持 Multi-AZ 部署（主实例 + 待机实例）
- Aurora Global Database 支持跨区域（最多 16 个区域）
- 单区域最多支持 15 个只读副本
| 对比项 | TiDB | Aurora |
|---|---|---|
| 跨 AZ 副本数 | 可配置（默认 3） | 固定 6（含 2 Learner） |
| 副本策略 | Placement Rules 精细控制 | 自动管理 |
| 跨区域方案 | TiCDC 异步复制 + 同城双集群 | Global Database（延迟约 1 秒） |
| AZ 级别切换 | 自动（Raft Leader 选举） | 自动（主实例故障转移） |
| 数据一致性 | Raft 多数派强一致 | 存储层 Quorum（4/6 写，3/6 读） |
3. 扩展方式对比
TiDB：三维度独立扩展
┌─────────────────┐
计算扩展 ───▶ │ TiDB Server │ (无状态，按需水平扩展)
├─────────────────┤
行存扩展 ───▶ │ TiKV Store │ (Raft Group 自动分裂)
├─────────────────┤
列存扩展 ───▶ │ TiFlash │ (异步复制，加速 OLAP)
└─────────────────┘
- 计算层：TiDB Server 无状态，可在线扩缩容，秒级生效
- 存储层：TiKV 数据量增长时自动分裂 Region，平衡负载
- 分析层：TiFlash 提供列存副本，HTAP 场景无需 ETL
Aurora：存储自动扩展 + 计算垂直/水平
- 存储层：自动扩展（最大 128 TB），无需手动分区
- 计算层：垂直扩展（实例规格变更）或水平扩展（只读副本增加）
- 限制：写入始终由主实例承载，无法水平扩展写入
-- TiDB：在线扩容（无需应用感知）
-- 执行 TiDB Operator 或 TiUP scale-out 即可
-- Aurora：扩容计算节点（需通过 AWS CLI 或控制台）
-- ALTER INSTANCE 修改实例规格可能需要重启
| 扩展场景 | TiDB | Aurora |
|---|---|---|
| 读取扩展 | 增加 TiDB Server（同时提升读写） | 增加只读副本（仅读） |
| 写入扩展 | 增加 TiKV 节点（水平扩展写入） | 升级主实例规格（垂直扩展） |
| 分析查询 | TiFlash 列存加速 | 无原生列存（需 Redshift） |
| 存储扩展 | 增加存储节点，在线自动均衡 | 自动扩展至 128 TB |
| 扩容影响 | 在线，业务无感知 | 垂直扩容可能需停机 |
4. 成本模型对比
典型场景成本估算（月度，中等负载）
| 资源 | TiDB 自建（3 节点最低配置） | TiDB Cloud (Serverless) | Aurora MySQL |
|---|---|---|---|
| 计算 | 3 × 8C16G ¥3,000 | 按需 ¥500-2,000 | 1 × db.r6g.xlarge ¥2,400 |
| 存储 | 3 × 500GB SSD ¥900 | 含在 Serverless 中 | 500GB ¥500 |
| 网络 | 跨 AZ 流量 ¥300 | 含在费用中 | 跨 AZ 流量 ¥200 |
| 估算总计 | ¥4,200/月起 | ¥500-2,000（按量） | ¥3,100/月起 |
成本关键差异
- TiDB 自建：初期投入较高，但写入可水平扩展，高负载下单位成本递减
- TiDB Cloud Serverless：按量计费，适合开发测试和低流量业务
- Aurora：中低负载下成本可控，但写入瓶颈到达后扩容成本快速上升
- 数据传输：TiDB 自建跨 AZ 流量需额外计费；Aurora 同区域内传输免费
引用：注意：以上价格为 2025 年参考估算，实际价格取决于区域、规格和折扣策略。建议使用各平台定价计算器获取精确报价。
5. 数据主权：多云 vs 单云锁定
| 维度 | TiDB | AWS Aurora |
|---|---|---|
| 部署灵活度 | 公有云 / 私有云 / 混合云 / 边缘 | 仅限 AWS |
| 多云支持 | 阿里云、AWS、GCP、Azure、腾讯云等 | 无（AWS 专属） |
| 数据迁移成本 | 标准协议（MySQL 兼容），迁移工具成熟 | 迁出需通过通用方案（如 DMS） |
| 云锁定风险 | 低（开源 + 多云部署） | 高（存储格式专有，协议受限） |
| 合规灵活性 | 可部署在任意满足合规要求的基础设施 | 受限于 AWS 区域和合规认证 |
多云策略的关键考量：
- 监管合规：金融、医疗等行业要求数据留存境内，TiDB 支持在任意云或本地部署
- 供应商风险：避免单一云服务商宕机、涨价或服务变更的影响
- 谈判筹码：多云部署能力可以提升与云厂商谈判时的议价能力
FAQ
Q1：TiDB 和 Aurora 的事务性能差距有多大？
在单节点事务场景下，Aurora 具有一定优势（约 10-20%），因为其避免了分布式事务开销。但在高并发写入（超过单节点容量）场景下，TiDB 可通过水平扩展持续提升吞吐，而 Aurora 需要垂直升级主实例。参考 TPC-C 基准测试，TiDB 在 1000 Warehouse 规模下可达到百万级 QPS。
Q2：Aurora 的存储自动扩展和 TiDB 的存储扩容有何本质区别？
Aurora 存储是逻辑上的单一卷，按需自动增长，不需要数据重新分布。TiDB 存储由多个 TiKV 节点组成，数据按 Range 分片，新数据写入会触发 Region 分裂和自动均衡。两种方案都支持在线扩容，但 TiDB 提供了更细粒度的存储资源控制。
Q3：TiDB 的学习曲线是否比 Aurora 更陡？
TiDB 的 MySQL 兼容性覆盖了绝大多数常见操作，应用迁移通常只需少量适配。但运维层面需要理解分布式概念（Region、Raft、Placement Rules）。Aurora 作为托管服务，运维更简单，但深度调优同样需要理解其存储架构。对于已经有 MySQL 运维经验的团队，TiDB 的学习成本通常在 1-2 个月内可消化。
Q4：如何从 Aurora 迁移到 TiDB？
推荐迁移路径：Aurora → 数据导出（mysqldump 或 AWS DMS）→ TiDB 导入。TiDB 提供了数据迁移工具 DM（Data Migration）和 Lightning（批量导入），支持全量+增量迁移。建议先在测试环境验证兼容性，再分批次迁移生产数据。
总结
TiDB 和 Aurora 代表了两条不同的云原生数据库路线：
- TiDB 适合需要水平扩展、HTAP 混合负载、多云部署和长期数据主权自主的场景。其分布式架构提供了更强的扩展性和灵活性。
- Aurora 适合深度绑定 AWS 生态、中等规模负载、希望最小化运维投入的团队。其共享存储设计在中低负载下提供了出色的性价比。
选择的关键在于：你的业务是否需要写入水平扩展、是否有多云需求、以及你对数据主权的重视程度。
下一步行动
- 免费试用 TiDB：TiDB Cloud Serverless 免费试用——零成本体验 TiDB 的分布式架构
- 获取多云部署方案：联系 TiDB 解决方案团队 获取定制化多云架构方案
- Aurora → TiDB 迁移评估：使用 TiDB Data Migration 工具 评估迁移工作量