TiDB、OceanBase、PolarDB架构深度对比：从技术差异到业务选型指南

在分布式数据库的选型道路上，TiDB、OceanBase、PolarDB 这三者常常同时出现在候选名单上。但需要明确的是，它们并非简单的“同品类竞品”，而是代表了三条截然不同的技术路线和架构哲学：

• TiDB 更像一个“面向 MySQL 生态的分布式 SQL + HTAP 平台”，其核心在于计算与存储的解耦、弹性扩容以及事务与分析的一体化。
• OceanBase 则更接近于“金融级原生分布式数据库内核”，强调强一致性、高可用性、多租户以及超大规模的 OLTP 处理能力。
• PolarDB 的定位是“云原生计算存储分离数据库体系”，主打共享存储、快速弹性伸缩和云上运维效率；而其分布式扩展能力则由 PolarDB-X 来承担。

因此，真正的选型难点从来不是判断“谁更强”，而是辨析“谁的架构假设与你的业务现实更为契合”。本文将从架构原理、事务实现、工程化能力、生产实践及适用边界五个维度，系统性地剖析三者的差异，并提供可落地的选型方法论。

一、核心结论：三种架构哲学，而非同题竞争

如果用一句话概括这三者的区别，可以这样理解：

维度	TiDB	OceanBase	PolarDB
核心定位	分布式 SQL + HTAP	金融级原生分布式 OLTP	云原生计算存储分离
典型架构	SQL 层 + PD 调度层 + TiKV/TiFlash 存储层	Shared-Nothing 一体化内核	共享存储集群，计算节点无状态；分布式场景由 PolarDB-X 承担
一致性机制	Multi-Raft + MVCC + 2PC	Multi-Paxos + MVCC + 分布式事务	共享存储强一致复制；分布式能力更多依赖 PolarDB-X
优势方向	MySQL 迁移、弹性扩展、实时 HTAP	核心交易、强一致、容灾、多租户	云上弹性、读写分离、低运维、快速扩容
典型短板	跨 Region 分布式事务成本敏感	学习曲线和运维门槛更高	单集群版写扩展有限，需区分 PolarDB 与 PolarDB-X
最适合谁	互联网、平台型业务、实时分析场景	银行、证券、支付、电信、政企核心系统	云上业务、流量波动大、重读轻写、中大型 SaaS

进一步浓缩成一句话：

• TiDB 赢在 “架构解耦 + HTAP 一体化”。
• OceanBase 赢在 “核心交易 + 多机房强一致 + 金融级稳定性”。
• PolarDB 赢在 “云原生共享存储 + 高弹性 + 运维效率”。

二、差异根源：从架构原点理解三条技术路线

2.1 TiDB：分布式 SQL 体系，强调计算与存储解耦

TiDB 采用了经典的分层架构设计：

• TiDB Server：无状态 SQL 层，负责解析、优化并生成分布式执行计划。
• PD (Placement Driver)：集群元数据与调度中心，负责全局时间戳分配、Region 调度和负载均衡。
• TiKV：基于 Raft 的行式存储事务引擎，承载 OLTP 负载。
• TiFlash：列式存储副本引擎，承载实时分析负载。

这种架构的核心价值不仅在于“水平扩展”，更在于它巧妙地将数据库中最难兼顾的几个维度拆解开来：

1. SQL 接入层可按连接数和并发需求独立扩容。
2. 事务存储层可按数据写入压力和数据容量独立扩容。
3. 分析存储层可按扫描、聚合、报表等分析压力独立扩容。

这正是 TiDB 在各类平台型业务中备受青睐的原因。它并非简单地替代 MySQL，而是在保持 MySQL 兼容性的前提下，将传统的“单机主从 + 中间件分库分表 + 数仓同步”这一复杂技术栈，收敛为一个统一的数据库系统。想深入了解分布式系统架构背后的原理，可以到 云栈社区 的相关板块进行交流。

2.2 OceanBase：原生分布式一体化内核，强调事务与资源控制

OceanBase 的设计思路与 TiDB 不同。它并非通过组合多个组件来构建分布式能力，而是从内核层面就是一个原生的分布式数据库：

• 每个 OBServer 节点都集成了 SQL 引擎、存储引擎和事务引擎的全部能力。
• 以 Zone、Partition/Tablet、Log Stream 为核心单元来组织数据和副本。
• 使用 OBProxy 作为智能访问路由层。
• 以 Tenant 为基本单元实现资源隔离与治理，构建数据库级别的多租户能力。

OceanBase 的强项在于 “将高可用、资源隔离、分区调度、事务一致性等核心能力深度集成在内核中”。这使得它在核心交易场景中极具竞争力，尤其是当业务面临以下挑战时：

• 对跨机房容灾有极高要求。
• 对 RPO（恢复点目标）/RTO（恢复时间目标）有严苛约束。
• 需要在单集群内服务多个业务租户并实现强隔离。
• 既需要分布式扩展能力，又无法接受传统中间件式分库分表带来的复杂治理成本。

从架构哲学上看，OceanBase 更接近于 “分布式时代的 Oracle/Teradata 风格内核”，而非单纯的“云时代的 MySQL 扩展器”。

2.3 PolarDB：共享存储云数据库，强调云上弹性与运维简化

评估 PolarDB 时需要区分其两个关键产品形态：

• PolarDB MySQL/PostgreSQL/Oracle 兼容版：核心是 计算与存储分离的共享存储架构。
• PolarDB-X：面向分布式扩展场景，承担数据分片、分布式事务和水平扩容能力。

典型的 PolarDB 集群版形态如下：

• 一个主节点（RW）负责处理所有写入。
• 多个只读节点（RO）负责承接读流量。
• 所有计算节点共享底层同一份分布式存储池。
• 计算节点基本无状态，可实现快速扩缩容。

这种架构天然契合云上数据库即服务（DBaaS）场景，因为它从根本上解决了传统主从架构的多个痛点：

1. 新增只读节点时无需全量复制数据，速度极快。
2. 存储容量可独立于计算资源进行弹性扩展。
3. 故障切换、备份恢复等运维操作更容易实现平台化、自动化。
4. 清晰的读写分离模型，让 SaaS 及互联网业务更容易接入。

重要提醒：PolarDB（集群版）和 PolarDB-X（分布式版）是定位不同的产品。前者首先是高性能的云原生关系型数据库集群，后者才是具备完整分布式能力的数据库。许多选型误区正源于将二者混为一谈。

三、深度对比：差异体现在哪些核心“底层能力”

3.1 数据组织方式

TiDB

• 数据以 Key-Value 形式存储在 TiKV 中。
• 数据按 Region（连续的 Key Range）进行切分。
• Region 是数据复制、迁移、负载均衡和调度的基本单位。
  这种设计带来两个直接影响：一是扩容和热点迁移非常灵活；二是所有 SQL 最终都会映射到 KV 层，因此复杂 SQL 的性能与底层键设计、索引布局以及热点 Key 的分布情况高度相关。

OceanBase

• 数据按表分区与 Tablet 进行组织。
• Tablet 绑定到 Log Stream 进行副本复制与日志管理。
• 分区不仅是数据分布的边界，也是事务处理和资源调度的重要对象。
  OceanBase 的优势在于 “分区与事务的协同更为紧密”，特别适合订单、账务、流水、清结算等具有明确大表、分区表及数据生命周期管理需求的业务。

PolarDB / PolarDB-X

• PolarDB 集群版本质上是共享存储上的 “单写多读” 架构。
• PolarDB-X 才负责数据分片路由、分布式查询执行和分布式事务。
  因此，如果你的核心诉求是 “增强单实例能力并享受云上弹性”，PolarDB 更合适；如果诉求是 “在水平分片后仍需保持完整的 SQL 能力”，则应重点评估 PolarDB-X。

3.2 一致性与事务实现

TiDB：MVCC + Percolator 风格 2PC + Raft
TiDB 的事务链路可简化理解为：

1. SQL 在 TiDB 层生成分布式执行计划。
2. 事务涉及的 Key 被定位到多个 Region。
3. 执行事务预写 (prewrite)。
4. 由 PD 分配全局时间戳。
5. 提交事务 (commit)。
6. 每个 Region 内部通过 Raft 协议保证副本一致性。
   其优点是通用、透明、扩展性强；代价是当事务跨越大量 Region 或数据分布不均产生热点时，延迟可能被放大。因此，TiDB 的工程优化重点常在于 “如何让事务尽量局部化”。

OceanBase：原生分布式事务 + Multi-Paxos + 全局时间服务
OceanBase 的事务模型更偏向核心 OLTP 设计：

• 副本复制依赖 Multi-Paxos 协议。
• 事务层负责跨分区的原子提交与一致性读。
• 借助全局时间服务和 MVCC 维持全局一致性快照。
  这一点对金融交易至关重要，因为金融系统真正关心的是：
• 双边记账（如转账）是否绝对原子。
• 在多分区、多分片环境下是否仍能保证一致的快照读。
• 在故障恢复后是否会出现“部分提交、部分可见”的中间状态。
  OceanBase 在这类问题上的设计更为 “厚重”，也因此更适合处理高价值、强一致的事务。

PolarDB：单集群强一致 + 区分产品形态的分布式能力
PolarDB 集群版的优势在于共享存储架构下的一致性复制与快速故障切换（Failover）。它适合：

• 单主写入场景。
• 通过多个只读节点扩展读能力。
• 需要快速弹性伸缩。
• 追求云上托管运维。
  但如果业务发展到需要 “写入横向扩展、跨分片事务、高并发分布式 OLTP” 的阶段，真正需要评估的是 PolarDB-X 的能力，而非勉强用 PolarDB 集群版进行不匹配的比较。

3.3 HTAP、分析与报表能力

TiDB
TiDB 的 TiFlash 列存副本是其 HTAP 能力的核心。它不是通过传统 ETL 将数据同步到数据仓库，而是将分析型副本直接置于同一数据库体系内，由优化器智能选择使用行存（TiKV）还是列存（TiFlash）来执行查询。
这意味着：

• 数据分析的实时性更好（分钟级甚至秒级）。
• 事务处理库与分析库之间的数据链路极短。
• 非常适合实时经营分析、风控画像、订单看板等场景。
  但需注意，TiFlash 并非无限替代离线数仓。对于超大宽表、复杂的离线建模、大规模历史数据归档分析，仍需对象存储或专业数仓配合。

OceanBase
OceanBase 同样支持分析能力和并行查询执行，但其产品优势首先体现在 “核心交易数据库” 定位上。如果你的主要矛盾是超高并发的 OLTP，OceanBase 优势明显；如果你的主要矛盾是 TP 与 AP 的强耦合，且追求一体化体验，TiDB 的路径往往更直接。

PolarDB
PolarDB 凭借共享存储、高速网络和只读节点扩展，在读多写少、分析查询较重的云上场景也能表现出色。但它的分析能力更多建立在 “高性能云数据库集群” 的架构之上，而非 TiDB 那种从存储引擎层面进行的“行列融合 HTAP”设计。

3.4 高可用与容灾模型

维度	TiDB	OceanBase	PolarDB
副本机制	Region 多副本（Raft）	Partition/Log Stream 多副本（Multi-Paxos）	共享存储多副本
故障切换	依赖 Raft 选主与各组件自身高可用设计	多 Zone + Paxos + 自动主备切换	主节点与只读节点间切换 + 共享存储保障
容灾重点	副本一致性、数据弹性迁移	核心交易连续性、跨机房强一致、RTO/RPO	云上托管服务、高可用、秒级恢复

如果你的组织有明确的 “两地三中心、同城双活、跨城容灾” 要求，OceanBase 通常会成为优先选项；如果更关注公有云上的高可用托管效率，PolarDB 更占优势；如果想基于开源体系构建分布式强一致数据库，TiDB 则提供了更大的灵活性和可控性。在云栈社区的数据库/中间件/技术栈板块，可以找到更多关于这些数据库高可用设计的讨论。

四、工程视角：高并发、可扩展与可运维性实战比较

架构优劣不能仅停留在理论设计，最终要回归工程实践。

4.1 高并发写入

TiDB 的关键问题：热点 Region
TiDB 具备扩展能力，但并非所有写入都能天然均匀分布。如果使用单调递增的主键、索引设计不当或某些账户/租户访问过热，就容易产生 Region 热点，导致单点写入压力放大。
工程建议：

• 避免单调递增主键成为写热点，可使用 AUTO_RANDOM、业务Hash前缀等方式打散。
• 控制大事务范围，避免单个事务覆盖过多 Region。
• 建立监控，及时发现并处理热点表、热点索引和热点 Region。

OceanBase 的关键问题：分区设计是否贴合业务访问路径
OceanBase 的吞吐上限很高，但前提是分区策略合理。如果分区键与业务的主要访问模式不一致，就会导致大量跨分区访问和分布式事务，性能变得不稳定。
工程建议：

• 分区键应优先与核心业务查询路径保持一致（如用户ID、商户ID）。
• 将租户、账户等天然业务边界作为分区维度。
• 明确冷热数据生命周期，利用分区裁剪和分区归档进行优化。

PolarDB 的关键问题：写扩展的边界
PolarDB 集群版非常擅长扩展读能力，但 “单主写入” 是其基本架构前提。如果业务瓶颈是写入吞吐量的横向扩展，仅靠增加只读节点无法解决。
工程建议：

• 读流量应优先路由到只读节点。
• 当写入瓶颈显现时，需提前评估向 PolarDB-X 演进、进行应用业务拆分或引入异步化机制。
• 切勿将“存储容量可独立扩展”误解为“写吞吐可无限横向扩展”。

4.2 可扩展性

TiDB
最容易实现线性扩展的方向是：

• SQL 接入能力（增加 TiDB Server）。
• KV 存储容量与分析能力（增加 TiKV/TiFlash 节点）。
  换言之，TiDB 在 “针对不同压力分量进行拆解和独立扩容” 方面最为灵活。

OceanBase
OceanBase 更适合 “围绕业务租户进行资源治理式扩展”：

• 为特定租户增加 CPU、内存、存储资源。
• 进行分区重平衡以均衡负载。
• 实现多租户间的资源隔离与配额管理。
  它的扩展与深度的资源治理绑定得更紧密。

PolarDB
PolarDB 最强的是 “云上极致的弹性伸缩体验”：

• 计算节点（包括只读节点）可快速增加。
• 存储容量可在线、平滑扩展。
  对于追求运维效率、发布速度和资源利用率的云上团队，这一点价值显著。这背后是强大的云原生/IaaS能力在支撑。

4.3 可运维性

从平台工程角度看，三者的运维心智模型差异显著：

• TiDB：组件角色清晰，开源生态成熟，监控工具丰富，适合具备一定平台化建设和运维能力的团队。
• OceanBase：能力强大，但同时对 DBA 和架构团队提出了更高的要求，需要深入理解其数据模型、事务机制和资源治理逻辑。
• PolarDB：最接近 “数据库即服务” ，许多复杂性（如备份、容灾、补丁升级）由云平台收口，适合希望降低自建数据库复杂度的团队。
  一个常见的认知误区是：将 “数据库能力强” 等同于 “维护成本低” 。实际上，越是面向核心交易和多租户治理的场景，越需要组织具备相应的数据库工程化能力。

五、生产级案例：三种典型业务场景如何落地

5.1 场景一：电商订单平台，交易与实时分析并重

业务特征：

• 每秒数万级订单写入。
• 需实时查询支付转化率、商家经营看板、商品销量排行。
• 希望避免维护复杂的 ETL 链路。
  优先考虑：TiDB
  原因：
• OLTP 事务由 TiKV 高效处理。
• 实时分析查询可直连 TiFlash 列存副本，延迟低。
• 兼容 MySQL 协议，应用迁移改造成本相对较低。
  建议架构：
  1. 交易核心表使用行存（TiKV），确保事务低延迟。
  2. 对订单表等热点表设计合理主键（如使用 AUTO_RANDOM），避免顺序写入热点。
  3. 经营分析类查询直接使用 TiFlash 副本。
  4. 历史归档数据可导入对象存储或离线数仓。
     示例建表：

     
     CREATE TABLE orders (
     order_id BIGINT PRIMARY KEY /* 在 TiDB 中可进一步结合 AUTO_RANDOM */,
     user_id BIGINT NOT NULL,
     merchant_id BIGINT NOT NULL,
     status TINYINT NOT NULL,
     amount DECIMAL(18,2) NOT NULL,
     created_at DATETIME NOT NULL,
     updated_at DATETIME NOT NULL,
     KEY idx_user_created (user_id, created_at),
     KEY idx_merchant_created (merchant_id, created_at)
     );

ALTER TABLE orders SET TIFLASH REPLICA 2;

**实时经营分析 SQL**：
```sql
SELECT
    merchant_id,
    COUNT(*) AS order_cnt,
    SUM(amount) AS gmv
FROM orders
WHERE created_at >= NOW() - INTERVAL 10 MINUTE
  AND status IN (1, 2, 3)
GROUP BY merchant_id
ORDER BY gmv DESC
LIMIT 100;

5.2 场景二：银行核心账务，强一致与数据零错误容忍

业务特征：

• 转账、记账、清结算是核心生命线。
• 跨机房容灾要求极高（RPO=0, RTO<30s）。
• 必须保证事务绝对原子性与完备可审计性。
• 常伴随 Oracle 迁移或双模兼容需求。
  优先考虑：OceanBase
  原因：
• 原生分布式事务能力与金融核心账务场景高度匹配。
• 多租户资源治理模型适合大型金融机构的多业务线管理。
• 对跨机房高可用、稳定性、数据隔离性的支持最为彻底。
  建议架构：
  1. 账户、流水表按机构号或账户号进行分区。
  2. 交易表与分录账本表按同一业务维度组织，尽量减少跨分区事务。
  3. 将日终批处理、跑批任务与在线交易隔离到不同的租户或资源池。
  4. 建立严格的审计日志、数据归档、备份恢复及容灾演练机制。
     核心转账事务示例：

     
     BEGIN;

UPDATE account
SET balance = balance - 1000
WHERE account_id = 'A1001'
AND balance >= 1000;

UPDATE account
SET balance = balance + 1000
WHERE account_id = 'B2001';

INSERT INTO account_ledger(
tx_id,
debit_account,
credit_account,
amount,
tx_time
) VALUES (
'TX202604180001',
'A1001',
'B2001',
1000,
NOW()
);

COMMIT;

这里真正重要的不是 SQL 语法，而是数据库能否在节点故障、机房网络抖动、主备切换等 **“坏场景”** 下，依然100%保证上述事务的 ACID 语义不被破坏。OceanBase 的核心价值正体现在这种极端情况下的 **“正确性”**。

#### 5.3 场景三：云上 SaaS 平台，读多写少，流量波动剧烈
**业务特征**：
*   服务海量多租户。
*   白天读查询（操作、报表）流量巨大，晚间批量任务繁重。
*   遇到大促、活动或月结时，流量波峰极为显著。
*   团队希望将运维、弹性等复杂性最大限度地交给云厂商。
**优先考虑**：`PolarDB`
**原因**：
*   共享存储 + 多只读节点架构天然为读扩展而生。
*   云上秒级弹性扩容与故障切换，成本低、效率高。
*   在非极端分布式写入的场景下，综合性价比突出。
**建议架构**：
1.  主节点承接所有写入请求。
2.  报表、查询、数据导出等只读操作，通过代理或配置强制路由到只读节点。
3.  结合缓存（如 Redis）和异步任务队列进一步削峰填谷。
4.  若未来单个租户的数据量或写入吞吐增长到需分片水平，再评估迁移至 PolarDB-X。

### 六、生产级代码补全：安全可靠的应用接入方式

数据库选型成功的一半取决于应用如何接入。以下提供一个面向 MySQL 协议数据库的生产级接入示例，适用于 TiDB、OceanBase MySQL 模式及 PolarDB MySQL。

#### 6.1 Spring Boot 数据源配置示例
```yaml
spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://db-proxy.prod:3306/order_center?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true
    username: app_user
    password: ${DB_PASSWORD}
    hikari:
      maximum-pool-size: 60
      minimum-idle: 10
      connection-timeout: 3000
      validation-timeout: 1000
      idle-timeout: 600000
      max-lifetime: 1800000
      transaction-isolation: TRANSACTION_READ_COMMITTED

注意点：

• 连接池大小需与数据库实例规格匹配，并非越大越好。
• 事务隔离级别应与业务一致性要求及数据库默认语义对齐。
• 应用应通过统一的代理层、VIP 或集群地址访问数据库，避免直连单个后端节点。

6.2 幂等下单服务示例

@Service
public class OrderService {

    private final JdbcTemplate jdbcTemplate;
    private final TransactionTemplate transactionTemplate;

    public OrderService(JdbcTemplate jdbcTemplate,
                        TransactionTemplate transactionTemplate) {
        this.jdbcTemplate = jdbcTemplate;
        this.transactionTemplate = transactionTemplate;
    }

    public Long createOrder(String requestId, Long userId, Long merchantId, BigDecimal amount) {
        return transactionTemplate.execute(status -> {
            Long existingOrderId = jdbcTemplate.query(
                "SELECT order_id FROM order_idempotent WHERE request_id = ?",
                rs -> rs.next() ? rs.getLong(1) : null,
                requestId
            );

            if (existingOrderId != null) {
                return existingOrderId;
            }

            Long orderId = jdbcTemplate.queryForObject(
                "SELECT NEXTVAL(order_seq)", Long.class
            );

            int inserted = jdbcTemplate.update(
                """
                INSERT INTO orders(order_id, user_id, merchant_id, status, amount, created_at, updated_at)
                VALUES (?, ?, ?, ?, ?, NOW(), NOW())
                """,
                orderId, userId, merchantId, 0, amount
            );

            if (inserted != 1) {
                throw new IllegalStateException("insert order failed");
            }

            jdbcTemplate.update(
                """
                INSERT INTO order_idempotent(request_id, order_id, created_at)
                VALUES (?, ?, NOW())
                """,
                requestId, orderId
            );

            return orderId;
        });
    }
}

这段代码体现了生产环境的三个基本原则：

• 幂等优先：通过 requestId 保证重试安全性。
• 事务最小化：事务内仅包含必须原子化的数据库操作。
• 主键生成策略明确：使用数据库序列或分布式方案，避免应用侧随意生成导致冲突或热点。

6.3 读写分离路由建议

public enum DataSourceRoute {
    WRITE,
    READ
}

@Aspect
@Component
public class ReadWriteRouteAspect {

    @Before("@annotation(ReadOnlyQuery)")
    public void routeRead() {
        DataSourceContextHolder.set(DataSourceRoute.READ);
    }

    @Before("@annotation(WriteCommand)")
    public void routeWrite() {
        DataSourceContextHolder.set(DataSourceRoute.WRITE);
    }

    @After("@annotation(ReadOnlyQuery) || @annotation(WriteCommand)")
    public void clear() {
        DataSourceContextHolder.clear();
    }
}

工程注意事项：

• 在 TiDB 和 OceanBase 的分布式场景下，读写路由需结合事务语义。例如，刚写入后的立即读，为保证一致性可能仍需路由到主副本。
• 在 PolarDB 场景中，读写分离收益直接，但需监控复制延迟，避免业务读到过期数据。
• 对于支付、库存扣减等需要强一致读的业务，务必通过注解或逻辑强制走主库或支持一致性读的从库。

七、选型边界：不问“能不能”，要问“长期代价是什么”

7.1 何时优先选 TiDB

适合：

• 现有业务深度依赖 MySQL 生态，希望平滑演进。
• 希望摆脱分库分表中间件的复杂性。
• 同时存在高频 OLTP 与实时数据分析（HTAP）需求。
• 团队具备开源体系运维能力或接受半托管服务。
  需谨慎：
• 需严格控制跨 Region 的大范围分布式事务。
• 热点写入场景要求团队具备较强的数据模型设计能力。
• HTAP 并非取代离线数仓，超大规模历史分析仍需数仓配合。

7.2 何时优先选 OceanBase

适合：

• 核心交易、账务、资金、清结算等金融级场景。
• 对 RPO/RTO、强一致性和审计追溯有极端要求。
• 需要进行 MySQL/Oracle 双兼容或 Oracle 替代。
• 大型集团、多业务线、严格的多租户资源治理场景。
  需谨慎：
• 架构和治理模型较重，需要配备成熟的 DBA 或平台团队。
• 分区设计、租户规划、容量治理必须前置，无法后期补救。
• 采购流程与组织配套的技术能力同样关键。

7.3 何时优先选 PolarDB

适合：

• 业务已深度部署在公有云（尤其是阿里云）上。
• 读多写少，或读流量波动远大于写流量。
• 希望将高可用、备份、监控等运维工作交给云平台。
• 中大型 SaaS、互联网活动营销、重报表查询场景。
  需谨慎：
• 需提前评估单主写入的吞吐上限是否满足未来业务增长。
• 严格区分 PolarDB 集群版与 PolarDB-X，明确产品边界。
• 若业务最终必然走向超大规模分布式写入，需提前规划演进路径。

八、实用选型方法：基于问题清单决策

建议在技术评审时，组织业务、架构、DBA、运维团队共同回答以下10个问题：

1. 核心矛盾是 写扩展、读扩展，还是 TP与AP一体化？
2. 是否需要 跨机房强一致 和严格的容灾指标（如 RPO=0）？
3. 当前是否深度依赖 MySQL，或涉及 Oracle 迁移？
4. 事务是否经常跨越不同账户、商户、租户或大范围分区？
5. 业务是否存在明显的 热点 Key、热点租户 或 热点时间段？
6. 未来三年的业务增长，主要驱动因素是 数据总量、并发请求量，还是 查询复杂度？
7. 团队更擅长 开源自建与深度定制，还是更倾向 云厂商全托管服务？
8. 是否需要强大的 多租户资源隔离与配额管理 能力？
9. 是否要求 分钟级甚至秒级的实时分析，且不愿维护独立的 ETL 管道？
10. 能否接受数据库选型与特定云厂商生态进行 深度绑定？

一旦清晰回答了这些问题，选型方向通常会自然收敛：

• 若 TP+AP一体化 需求明确，且期望 MySQL 平滑升级，优先评估 TiDB。
• 若 核心交易+强一致+容灾+多租户治理 需求明确，优先评估 OceanBase。
• 若 云上托管+读扩展+弹性+运维效率 需求明确，优先评估 PolarDB。

九、常见认知误区

误区一：把基准测试分数直接当选型依据
基准测试仅反映特定配置、特定负载模型下的性能。真正影响生产环境表现的因素复杂得多：SQL模式是否贴合数据库优化器、数据分布是否均衡、事务是否跨分区、索引设计是否合理，以及应用层的幂等、重试、连接治理是否到位。

误区二：认为“兼容 MySQL”就意味着零改造
兼容协议和大部分语法，不等于行为完全一致。执行计划、锁机制、部分系统变量和边界条件下的行为可能存在差异。迁移项目中，最易出问题的往往是 SQL 编写习惯、事务边界划分和运维操作方式，而非 DDL 语法。

误区三：数据库选型只看技术，不看组织能力
数据库是组织技术能力的放大器。

• 擅长平台工程、愿意投入架构治理的团队，使用 TiDB 会如鱼得水。
• 具备深厚核心数据库治理经验的团队，能最大化释放 OceanBase 的价值。
• 追求快速交付、希望降低基础设施复杂度的团队，从 PolarDB 中获得的收益最为直接。

十、总结：将数据库视为业务架构的一部分

TiDB、OceanBase、PolarDB 之间的差异，本质上是 “优先解决哪类业务问题” 的路径差异，而非单纯的技术先进性比拼。

• TiDB 致力于解决分布式 SQL 与 HTAP 一体化问题，是平台型业务进行弹性扩展和实时分析的优秀选择。
• OceanBase 致力于解决金融级核心 OLTP、强一致和高可用问题，是关键业务系统的坚实底座。
• PolarDB 致力于解决云上数据库弹性、存储共享与运维效率问题，是云原生业务应对流量波动的利器。

对于架构师而言，最稳妥的决策方法不是追问“哪个数据库最好”，而是叩问自己：
我的业务，当前及未来最主要的矛盾究竟是什么？

如果你正准备进行技术落地，建议将评估工作收敛为三件具体事项：

1. 场景化 PoC：选取3条最核心、最具代表性的业务链路进行验证，而非只运行标准化基准测试。
2. 演进式评估：基于未来2-3年的业务容量、并发增长及团队能力进行规划，而非仅考量当前成本。
3. 全局成本核算：综合评估数据库能力、迁移改造成本、长期运维复杂度及容灾演练开销。

通过这种方式做出的选型，才不再是简单的“数据库产品采购”，而是能够真正支撑业务长期稳健发展的 “架构战略决策”。