┌─ 应用层 ──────────────────────────────────┐
│  MySQL Client / JDBC / ORM                │
└──────────────────┬────────────────────────┘
                   │ MySQL 协议
┌─ TiDB (SQL 层) ──┴────────────────────────┐
│  SQL 解析 → 优化 → 执行                    │
│  无状态，可水平扩展                         │
└──────┬──────────────┬────────────────────┘
       │              │
┌─ PD (调度层) ─┐ ┌─ TiKV (存储层) ─────────┐
│  元数据管理    │ │  Raft 一致性协议         │
│  调度决策      │ │  行存储，事务支持         │
│  时间戳分配    │ │  可水平扩展              │
└───────────────┘ └──────┬──────────────────┘
                         │ 异步复制
                  ┌─ TiFlash (列存) ───────┐
                  │  列式存储，分析加速       │
                  │  与 TiKV 实时同步        │
                  └────────────────────────┘

核心组件说明：

TiDB Server：SQL 层，负责解析、优化和执行 SQL，无状态设计，可按需扩缩容。
PD（Placement Driver）：集群的大脑，管理元数据、调度 Region 和分配时间戳。通常部署 3 个节点保证高可用。
TiKV：基于 Raft 协议的分布式 Key-Value 存储引擎，行存储，承载 OLTP 负载。
TiFlash：列式存储引擎，通过异步 Raft Learner 机制从 TiKV 实时同步数据，加速分析查询。

核心优势

水平扩展：计算层和存储层均可独立扩容，数据自动均衡。
MySQL 兼容：支持绝大多数 MySQL 语法和工具，迁移成本低。
HTAP 能力：一套数据库同时处理事务和分析，避免 ETL 链路。
资源控制：TiDB 7.x 引入 Resource Control，支持按用户/会话限制 CPU、IO 资源，实现多租户隔离。

生产部署建议

# 最小生产集群（3 节点起步）
PD:      3 节点（建议 4C8G 起）
TiKV:    3 节点（建议 8C32G + SSD）
TiDB:    2 节点（建议 8C16G 起）
TiFlash: 按分析需求选配（建议 8C64G 起）

# 关键配置
# TiKV rocksdb 的 block cache 建议设为机器内存的 30%-40%
# PD 调度参数需要根据实际负载调整
# 开启 TiDB Dashboard 和 Prometheus + Grafana 监控

TiDB 7.x 版本（2024-2025）是企业部署的主流版本，支持资源控制、索引加速、增强的执行计划管理等特性。TiDB Serverless 云服务也已上线，适合初创团队快速起步。

OceanBase

产品定位

OceanBase 由蚂蚁集团开发，最初服务于支付宝等核心金融业务。它是一款金融级分布式关系型数据库，在 2021 年的 TPC-C 基准测试中以 7.07 亿 tpmC 的成绩刷新了世界纪录。OceanBase 4.x 版本实现了单机分布式一体化架构，降低了中小规模场景的部署门槛。

架构

OceanBase 采用一体化架构设计：

单机分布式一体化：一套代码同时支持单机部署和分布式部署，单机模式下资源消耗接近传统单机数据库。
多租户架构：原生支持资源隔离，不同租户的 CPU、内存相互独立。
Paxos 一致性协议：数据副本间基于 Multi-Paxos 实现强一致，支持少数派故障自动切换。
LSM-Tree 存储引擎：写入友好，适合高并发写入场景。

┌─ OBServer 节点 ─────────────────────┐
│  ┌─ SQL 引擎 ─┐  ┌─ 事务引擎 ─┐    │
│  │  解析/优化   │  │  分布式事务  │    │
│  │  分布式执行  │  │  两阶段提交  │    │
│  └────────────┘  └────────────┘    │
│  ┌─ 存储引擎 ──────────────────┐    │
│  │  LSM-Tree + 多版本并发控制    │    │
│  │  数据分区 + 多副本 Paxos     │    │
│  └─────────────────────────────┘    │
└─────────────────────────────────────┘

核心优势

金融级高可用：RPO=0，RTO<30 秒，支持同城三机房、三地五中心等部署模式。
Oracle/MySQL 双兼容：支持 Oracle PL/SQL 和 MySQL 语法，方便从不同源库迁移。
单机分布式一体化：小规模场景单机部署，业务增长后无缝扩展为分布式集群。
多租户隔离：资源层面硬隔离，适合 SaaS 和 DBaaS 场景。

应用案例

OceanBase 在金融行业有广泛验证：支付宝核心交易系统、多家国有大行和股份制银行的核心账务系统、多家保险公司和券商的交易系统均运行在 OceanBase 之上。截至 2025 年，OceanBase 已服务超过 1000 家金融机构。

openGauss

产品定位

openGauss 由华为主导开源，内核基于 PostgreSQL 深度定制。它在 PostgreSQL 的基础上增强了安全性、性能和可维护性，并在 ARM 架构上做了专门优化。openGauss 采用 MulanPermissive 2.0 协议开源，社区版可免费使用。

架构

openGauss 支持两种部署模式：

单机主备模式（适合中小规模）：

┌─ 主库 (Primary) ────────┐
│  读写                     │
│  WAL 日志                 │
└──────────┬───────────────┘
           │ 同步/异步复制
┌─ 备库 (Standby) ────────┐
│  只读 / 故障切换          │
│  可配置多个级联备库       │
└─────────────────────────┘

分布式模式（适合大规模）：

┌─ openGauss 集群 ─────────────────────┐
│  ┌─ ShardingSphere（中间件层） ──┐   │
│  │  SQL 路由 / 分片 / 读写分离    │   │
│  └──────────┬────────────────────┘   │
│             │                        │
│  ┌─ DN1 ─┐ ┌─ DN2 ─┐ ┌─ DN3 ─┐    │
│  │ 主+备 │ │ 主+备 │ │ 主+备 │    │
│  └───────┘ └───────┘ └───────┘    │
└─────────────────────────────────────┘

核心优势

PostgreSQL 生态兼容：支持 SQL 标准和 PostgreSQL 语法，大量 PG 生态工具可直接使用。
ARM 优化：在华为鲲鹏处理器上有专门的性能调优，在 ARM 环境下表现优异。
安全增强：支持全密态数据库、透明数据加密（TDE）、国密算法（SM2/SM3/SM4）。
内核深度优化：在执行器、优化器和存储引擎层面做了大量增强。

openGauss 6.x 版本（2024-2025）是当前社区维护的主流大版本，增强了分布式能力、提升了并发性能，并改善了 DBA 运维体验。社区已有超过 300 家企业参与贡献。

达梦 DM8

产品定位

达梦数据库（武汉达梦数据库有限公司）是国内历史最悠久的数据库厂商之一，DM8 是其旗舰产品。达梦坚持纯自研内核路线，不基于任何开源数据库修改。DM8 最大的差异化优势是对 Oracle 的兼容性，在国产数据库中 Oracle 兼容度最高。

核心特性

Oracle 兼容性：支持 PL/SQL、Oracle 数据类型、内置函数、DBMS 包等，Oracle 迁移改造成本最低。
安全合规：通过等保四级、军用认证，支持国密算法。
集中式架构：主备集群方案成熟，部署和运维相对简单。
政务军工场景：在政府、军工、公安等领域有大量落地案例，是这些领域的首选之一。

达梦 DM8 为闭源商业产品，按 License 授权收费。由于完全自研内核，在某些前沿特性上与开源社区驱动的产品存在差距，但在稳定性和 Oracle 兼容方面具有独特优势。

国产数据库对比

维度	TiDB	OceanBase	openGauss	DM8	PolarDB
类型	分布式 HTAP	分布式关系型	集中式/分布式	集中式关系型	云原生关系型
开源	是（Apache 2.0）	是（核心开源）	是（MulanPermissive）	否	否
MySQL 兼容	高	高	否（PG 兼容）	否（Oracle 兼容）	高
Oracle 兼容	否	中	否	高	否
水平扩展	原生支持	原生支持	需加中间件	有限	云原生扩展
HTAP	原生（TiFlash）	支持（内部引擎）	否	否	否（需搭配分析产品）
ARM 优化	通用	通用	深度优化	支持	通用
国密算法	否	部分	是	是	否
部署模式	自建/云	自建/云	自建/云	自建	阿里云
适用场景	互联网、中型企业	金融、大型企业	政务、通信	政务、军工	阿里云用户
学习成本	中	中	低（PG 用户）	低（Oracle 用户）	低

兼容性：与现有应用的 SQL、驱动、工具兼容度
性能：在业务真实负载下的 QPS/TPS 和延迟表现
可用性：RPO/RTO 指标、故障切换机制
安全性：等保、国密、审计等合规要求
生态：社区活跃度、文档质量、第三方工具支持
成本：License 费用、硬件要求、运维人力

国产数据库高可用架构

TiDB 高可用（Multi-Raft + PD 调度）

TiDB HTAP 架构：

┌─ TiDB Server × N（无状态 SQL 层）───┐
│  解析 SQL、生成执行计划               │
│  通过 PD 获取数据分布信息             │
│  负载均衡，任一节点可接受请求         │
└──────────────┬──────────────────────┘
               │
┌─ PD (Placement Driver) × 3 ─────────┐
│  集群元数据管理（Raft 选举 Leader）  │
│  Region 调度、负载均衡               │
│  时间戳分配（TSO）                   │
└──────────────┬──────────────────────┘
               │
┌─ TiKV × N（行存，Raft 复制）─────────┐
│  数据按 Region（96MB）分片            │
│  每个 Region 3 副本（Multi-Raft）     │
│  Region 1: Leader=kv1, Follower=kv2,kv3 │
│  Region 2: Leader=kv2, Follower=kv1,kv4 │
│  ...                                  │
│  PD 自动调度 Region 均衡              │
└──────────────┬──────────────────────┘
               │
┌─ TiFlash × N（列存，异步复制）───────┐
│  从 TiKV 异步复制数据                 │
│  列式存储，加速分析查询               │
│  HTAP：行存+列存同时可用              │
└───────────────────────────────────────┘

高可用保证：
- Region 3 副本跨节点分布
- Leader 故障自动选举（秒级）
- PD 感知节点状态，自动调度 Region
- 节点宕机数据零丢失（Raft 多数派确认）

OceanBase 高可用（Paxos 分布式共识）

OceanBase 单机分布式一体化架构：

┌─ Zone 1 ──────────┐ ┌─ Zone 2 ──────────┐ ┌─ Zone 3 ──────────┐
│  OBServer          │ │  OBServer          │ │  OBServer          │
│  Paxos Leader      │ │  Paxos Follower    │ │  Paxos Follower    │
│  (部分 Partition)  │ │  (部分 Partition)  │ │  (部分 Partition)  │
│                    │ │                    │ │                    │
│  读 + 写           │ │  读（可配置）      │ │  读（可配置）      │
└────────────────────┘ └────────────────────┘ └────────────────────┘

高可用特性：
- 每个数据分区 3 副本（Paxos 协议）
- Leader 故障自动选举（< 30 秒）
- RPO = 0（同步确认，数据零丢失）
- RTO < 30 秒（自动切换时间）
- 跨 Zone 部署（同城双活）
- 跨 Region 部署（异地容灾）

金融级案例：支付宝双 11 验证，可用性 99.999%

openGauss 高可用（主备 + 流复制 + etcd）

openGauss 高可用架构（类似 PostgreSQL + Patroni）：

┌─ etcd Cluster ─────────────────┐
│  分布式锁、元数据存储           │
└──────────┬─────────────────────┘
           │
┌─ Primary ──────────────────────┐
│  WAL 日志流复制到 Standby       │
│  通过 etcd 持有 Leader 锁      │
└──────────┬─────────────────────┘
     ┌─────┴──────┐
┌─ Standby ──┐ ┌─ Cascade Standby ─┐
│ 同步复制   │ │ 异步复制           │
│ 可自动提升 │ │ 异地容灾           │
└────────────┘ └────────────────────┘

故障切换：
- Primary 宕机 → etcd 锁过期
- Standby 竞争锁 → 提升为新 Primary
- 切换时间：10-30 秒
- openGauss 支持备机可读（类似 Hot Standby）

分布式方案（openGauss + ShardingSphere）：
┌─ ShardingSphere-Proxy ─────┐
│  SQL 路由、分片、读写分离   │
└──────────┬──────────────────┘
     ┌─────┼─────┐
┌─ Shard 1 ─┐ ┌─ Shard 2 ─┐ ┌─ Shard 3 ─┐
│ Primary +  │ │ Primary +  │ │ Primary +  │
│ Standby    │ │ Standby    │ │ Standby    │
└────────────┘ └────────────┘ └────────────┘

国产数据库高可用对比

维度	TiDB	OceanBase	openGauss	达梦 DM8
共识协议	Multi-Raft	Paxos	流复制+etcd	自研主备
自动切换	是（秒级）	是（<30s）	是（10-30s）	是
RPO	0	0	≈0（同步）	取决于配置
数据分片	自动 Region	自动 Partition	需 ShardingSphere	手动
水平扩展	原生支持	原生支持	需中间件	有限
跨地域容灾	支持	支持	支持	支持

迁移路径

从 Oracle 迁移

Oracle 到国产数据库的迁移是难度最高的一类，主要挑战在于 PL/SQL 存储过程、Oracle 内置包和特有语法。

推荐目标：DM8（兼容性最佳）或 OceanBase（Oracle 模式）。

迁移步骤：

评估阶段：梳理 Oracle 版本、字符集、存储过程、触发器、自定义类型等，建立迁移清单。
Schema 迁移：使用达梦 DTS 或 OceanBase OMS 工具自动转换表结构、索引、约束。
存储过程改造：逐个审查 PL/SQL 代码，处理不兼容的语法和内置包调用，这部分工作量最大。
数据迁移：全量导出导入 + 增量同步，确保迁移窗口内数据一致。
应用适配：修改 JDBC 连接、SQL 语句和 ORM 配置，执行回归测试。
割接上线：选择业务低峰期执行最终切换，保留回滚方案。

从 MySQL 迁移

MySQL 到国产数据库的迁移相对简单，得益于 TiDB、OceanBase、PolarDB 都对 MySQL 有较好的兼容性。

推荐目标：TiDB、OceanBase 或 PolarDB。

迁移步骤：

兼容性检查：使用 dumpling + tiup 的预检工具或 OceanBase OMS 的评估功能，识别不兼容的 SQL 特性。
数据导出：使用 mydumper 或 mysqldump 导出全量数据。
数据导入：TiDB 使用 TiDB Lightning 加速导入；OceanBase 使用 OBLOADER；PolarDB 使用云上 DTS 服务。
增量同步：使用 DM（TiDB Data Migration）或 Canal 配置 MySQL 到目标库的实时同步。
验证与切换：应用连接到目标库进行灰度验证，确认无误后切换流量。

# TiDB 迁移示例：使用 Dumpling 导出 + Lightning 导入

# 1. 导出 MySQL 数据
dumpling \
  -h 10.0.0.1 -P 3306 -u root -p'xxx' \
  -o /data/export \
  --threads 8 \
  --filetype sql

# 2. 导入到 TiDB
tidb-lightning \
  --tidb-host=10.0.0.2 \
  --tidb-port=4000 \
  --tidb-user=root \
  --tidb-password='xxx' \
  --importer-host=10.0.0.3 \
  --importer-port=8287 \
  --dir /data/export \
  --log-file /var/log/lightning.log

# 3. 配置增量同步（DM）
dmctl start-task ./dm-task.yaml

通用迁移注意事项

字符集：确认源库和目标库的字符集一致，常见问题为 GBK 与 UTF-8 的转换。
自增 ID：部分国产数据库的自增行为与 MySQL/Oracle 不同，需要验证。
事务隔离级别：TiDB 默认快照隔离（SI），openGauss 默认读已提交（RC），需确认应用依赖的隔离级别。
驱动适配：更换 JDBC 驱动，注意连接参数的变化。

挑战与展望

当前挑战

生态成熟度：虽然国产数据库在核心功能上已逐步追平国际产品，但在周边工具链（监控、审计、数据治理）方面仍有差距。DBA 工具、第三方备份方案、数据集成平台的支持不够完善。

人才储备：熟悉 Oracle/MySQL 的 DBA 很多，但具备国产数据库运维经验的工程师仍然稀缺。企业在国产化替代过程中，往往需要投入大量资源进行人员培训。

性能对比：在极端场景下（超大规模数据量、复杂分析查询），国产数据库与国际顶尖产品仍有差距。但在大多数企业级应用场景中，性能差距已不明显。

迁移成本：大型系统的数据库迁移涉及应用改造、数据迁移、测试验证和割接切换，整体周期可能长达 6-12 个月，投入的人力成本不可低估。

发展趋势

云原生加速：云原生数据库（PolarDB、TDSQL、GaussDB）的采用率持续上升，存算分离架构成为主流。越来越多的企业选择直接在云上使用国产数据库服务。

AI 融合：向量数据库和 AI 原生能力正在成为国产数据库的新竞争维度。TiDB 7.x 已支持向量索引，OceanBase 也在规划 AI 相关能力。

开源生态：TiDB、openGauss、OceanBase 等开源项目的社区活跃度持续增长。开源策略降低了用户试用门槛，也加速了产品迭代。

政策持续推动：信创政策从"可用"走向"好用"阶段，对国产数据库的性能、稳定性和生态提出了更高要求。2026 年及以后，金融、电信、能源等行业的核心系统替代将进入深水区。

国产化数据库替代是一个系统性工程，技术选型只是第一步。选择与自身业务匹配、团队能力匹配的数据库产品，制定合理的迁移策略和应急预案，才能确保国产化替代顺利落地。