内容阅读

在知识库中专注阅读，并随时返回相关工具与课程

运维管理21 分钟阅读

国产数据库横向评测：TiDB vs OceanBase vs openGauss 部署实战与性能对比

信创浪潮下，国产数据库选型成了 DBA 绑不开的话题。TiDB、OceanBase、openGauss 是目前最主流的三大国产数据库。本文从架构设计、部署体验、兼容性、性能表现四个维度做横向评测，并给出不同场景下的选型建议。

2026年5月6日阅读—点赞—收藏—

mysqlpostgresql

打开目录

写在前面

最近两年，"信创" 这个词在 IT 圈的热度只增不减。简单说，信创就是 信息技术应用创新，核心目标是实现关键技术的自主可控。数据库作为基础软件的 "三驾马车" 之一（操作系统、数据库、中间件），自然成了信创替代的重中之重。

如果你是一线 DBA，或者正在做技术选型，你一定绑不开这三个名字：

TiDB — PingCAP 出品，分布式 NewSQL 的代表
OceanBase — 蚂蚁集团出品，金融级分布式数据库
openGauss — 华为出品，基于 PostgreSQL 的增强型数据库

我从去年开始陆续在测试环境把这三款数据库都跑了一遍，今天这篇文章就把我的实际体验分享出来。不吹不黑，用数据和部署日志说话。

一、为什么要关注国产数据库？

1.1 政策驱动

2025 年之后，党政、金融、电信、能源等关键行业的核心系统，已经在加速推进国产数据库替代。很多招标文件里明确写着"优先采用国产数据库"。这不是趋势，是现实。

1.2 技术已经成熟

五年前你可能还会说 "国产数据库不靠谱"，但今天情况完全不同了：

TiDB 已经在头部互联网公司的核心交易系统上线
OceanBase 连续多年打破 TPC-C 世界纪录
openGauss 在政务、电力等行业有大量落地案例

说白了，现在不是 "能不能用" 的问题，而是 "选哪个" 的问题。

1.3 Oracle/MySQL 迁移压力

Oracle 的授权费用大家都懂，一台物理机一年几十万的 License 费用，很多企业已经扛不住了。MySQL 虽然开源，但在分布式扩展、企业级高可用方面确实有短板。国产数据库恰好填补了这个空间。

二、TiDB：分布式 NewSQL 的标杆

2.1 架构概览

TiDB 的架构设计非常清晰，核心由三个组件构成：

TiDB Server、TiKV 与 PD 的架构关系 TiDB Server、TiKV 与 PD 的架构关系

关键设计点：

TiDB Server：负责 SQL 解析和执行，本身不存数据，天然支持水平扩展。你可以理解为它就是一个 "计算节点"。
TiKV：底层存储引擎，数据按 Region 分片，每个 Region 默认 96MB。Region 之间通过 Raft 协议保证强一致性。
PD (Placement Driver)：集群的 "大脑"，负责 Region 调度、TSO（全局时间戳）分配和元数据管理。
TiFlash（可选）：列式存储引擎，实时同步 TiKV 的数据，专门用于 OLAP 分析查询。这就是 TiDB 所谓的 HTAP 能力。

2.2 MySQL 兼容性

TiDB 兼容 MySQL 5.7/8.0 协议，大部分 MySQL 客户端和 ORM 框架可以直接连。但要注意几个坑：

自增 ID 不连续：TiDB 的自增 ID 是分段分配的，不保证连续递增。如果你的业务依赖自增 ID 的连续性，需要提前改造。
事务大小限制：默认单个事务的 KV 对数量限制在 txn-total-size-limit = 100MB，大批量 INSERT 需要分批处理。
部分 MySQL 函数不支持：比如 CREATE PROCEDURE 的支持是实验性的，存储过程重度用户需要留意。
外键约束：从 v6.6 开始支持，但建议在分布式场景下慎用。

实际迁移中，大概 80-90% 的 MySQL 应用可以平滑迁移到 TiDB，剩下的需要做一些改造。

2.3 部署实战：TiUP 一键拉起

TiDB 的部署体验是三者中最丝滑的，核心工具是 TiUP。

第一步：安装 TiUP

Bash

1curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
2source ~/.bashrc

第二步：准备拓扑文件

YAML

1# topology.yaml
2
3> **本章目标**：掌握本章核心知识点
4> **前置要求**：完成前序章节学习
5> **预计时长**：60 分钟
6
7global:
8  user: "tidb"
9  ssh_port: 22
10  deploy_dir: "/tidb-deploy"
11  data_dir: "/tidb-data"
12
13server_configs:
14  tidb:
15    log.slow-threshold: 300
16  tikv:
17    readpool.storage.use-unified-pool: true
18    readpool.coprocessor.use-unified-pool: true
19  pd:
20    replication.location-labels: ["host"]
21
22tidb_servers:
23  - host: 10.0.1.1
24  - host: 10.0.1.2
25
26tikv_servers:
27  - host: 10.0.1.1
28  - host: 10.0.1.2
29  - host: 10.0.1.3
30
31pd_servers:
32  - host: 10.0.1.1
33  - host: 10.0.1.2
34  - host: 10.0.1.3
35
36monitoring_servers:
37  - host: 10.0.1.1
38
39grafana_servers:
40  - host: 10.0.1.1

第三步：一键部署

Bash

1tiup cluster deploy tidb-test v7.6.0 ./topology.yaml --user root -p
2tiup cluster start tidb-test

部署完成后，TiUP 会自动帮你配好 Prometheus + Grafana 监控，开箱即用。这一点真的要给好评。

第四步：验证连接

Bash

1mysql -h 10.0.1.1 -P 4000 -u root

没错，直接用 MySQL 客户端连，端口默认是 4000。

2.4 HTAP 能力：TiFlash

TiFlash 是 TiDB 的杀手锏之一。你可以对某张表开启 TiFlash 副本：

SQL

1ALTER TABLE orders SET TIFLASH REPLICA 1;

之后，TiDB 的优化器会自动判断：如果是简单的点查或小范围扫描，走 TiKV（行存）；如果是大范围聚合分析，走 TiFlash（列存）。整个过程对应用完全透明。

实际测试中，同一张 5000 万行的订单表：

走 TiKV 做 SELECT COUNT(*) ... GROUP BY 需要 12 秒
走 TiFlash 只需要 0.8 秒

这就是列存的威力。

2.5 TiDB 优缺点总结

优势：

水平扩展能力强，加节点就能线性扩容
MySQL 协议兼容，迁移成本相对低
社区活跃，GitHub 36k+ Star，文档齐全
HTAP 能力成熟，一套系统搞定 TP + AP
TiUP 工具链完善，运维体验好

劣势：

资源消耗大，最小部署需要 3 台服务器（生产环境建议 6 台以上）
调优复杂，Raft Region 调度、GC 等参数需要经验
单机性能不如 MySQL，不适合小规模业务
学习曲线较陡（虽然用 MySQL 协议，但底层逻辑完全不同）

三、OceanBase：金融级分布式数据库

3.1 架构概览

OceanBase 采用 Shared-Nothing 架构，核心概念包括：

OceanBase 三 Zone 与 OBProxy 架构 OceanBase 三 Zone 与 OBProxy 架构

关键设计点：

Zone：OceanBase 的核心高可用单元。一般部署 3 个 Zone，分布在不同机房或可用区。数据在 Zone 之间通过 Paxos 协议 保持强一致。
OBServer：每个 Zone 里的数据库服务进程，集计算和存储于一体。
OBProxy：SQL 路由代理，负责将请求转发到正确的 OBServer。
租户（Tenant）：OceanBase 的资源隔离单元，类似 "数据库实例"。一个集群可以创建多个租户，每个租户有独立的 CPU、内存配额。

3.2 MySQL + Oracle 双兼容

OceanBase 最大的特色之一是同时兼容 MySQL 和 Oracle 两套语法模式：

SQL

1-- 创建 MySQL 模式租户
2CREATE TENANT mysql_tenant 
3  RESOURCE_POOL_LIST = ('pool_mysql')
4  SET ob_compatibility_mode = 'mysql';
5
6-- 创建 Oracle 模式租户
7CREATE TENANT oracle_tenant 
8  RESOURCE_POOL_LIST = ('pool_oracle')  
9  SET ob_compatibility_mode = 'oracle';

Oracle 兼容模式支持：

PL/SQL 语法（包括包、存储过程、触发器）
Oracle 数据类型（NUMBER、VARCHAR2、DATE 等）
Oracle 内置函数（NVL、DECODE、TO_CHAR 等）
DBMS_OUTPUT 等常用包
同义词（SYNONYM）和序列（SEQUENCE）

对于 Oracle 迁移来说，这个功能简直是救命稻草。实际测试中，大约 70-80% 的 Oracle PL/SQL 代码可以在 OceanBase Oracle 模式下直接运行。

3.3 部署实战：OBD 工具

OceanBase 的部署工具是 OBD (OceanBase Deployer)。

第一步：安装 OBD

Bash

1# CentOS/RHEL
2sudo yum install -y yum-utils
3sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo
4sudo yum install -y ob-deploy
5
6# 或者用 rpm 包
7rpm -ivh ob-deploy-*.rpm

第二步：单机快速部署（测试环境）

Bash

1# 单机 all-in-one 部署，适合学习和测试
2obd demo

这个命令会在本地拉起一个最小化的 OceanBase 实例，包含 1 个 OBServer + 1 个 OBProxy。

第三步：集群部署（生产环境）

YAML

1# mini-distributed.yaml
2oceanbase-ce:
3  servers:
4    - name: server1
5      ip: 10.0.1.1
6    - name: server2
7      ip: 10.0.1.2
8    - name: server3
9      ip: 10.0.1.3
10  global:
11    devname: eth0
12    memory_limit: 16G
13    datafile_size: 100G
14    log_disk_size: 100G
15    cpu_count: 16
16    mysql_port: 2881
17    rpc_port: 2882
18    home_path: /home/admin/oceanbase
19    zone: zone1
20  server1:
21    zone: zone1
22  server2:
23    zone: zone2
24  server3:
25    zone: zone3
26
27obproxy-ce:
28  servers:
29    - 10.0.1.1
30  global:
31    listen_port: 2883
32    prometheus_listen_port: 2884
33    home_path: /home/admin/obproxy
34    obproxy_sys_password: ******
35    observer_sys_password: ******

Bash

1obd cluster deploy ob-test -c mini-distributed.yaml
2obd cluster start ob-test

注意事项：

OceanBase 对内存要求较高，单个 OBServer 建议至少 16GB 内存
启动过程比较慢（Bootstrap 阶段需要 2-5 分钟），不要以为卡死了就 Ctrl+C
第一次登录用 root@sys 租户：mysql -h 10.0.1.1 -P 2881 -u root@sys

3.4 Zone 级高可用

OceanBase 的高可用设计非常硬核：

RPO = 0：基于 Paxos 协议，只要多数派 Zone 存活，数据零丢失
RTO < 30 秒：节点故障后，Paxos 自动选主，业务恢复时间在 30 秒以内
三地五中心：支持跨城部署，在城市级别的灾难下也能保证数据安全

蚂蚁每年双十一用的就是 OceanBase，金融级可靠性不是吹的。

3.5 OceanBase 优缺点总结

优势：

金融级高可靠，Paxos 强一致，RPO = 0
MySQL + Oracle 双兼容，Oracle 迁移友好
多租户资源隔离，一套集群服务多个业务
压缩率高，LSM-Tree 存储引擎自带压缩，实测存储空间约为 MySQL 的 1/3
TPC-C 世界纪录保持者，性能过硬

劣势：

学习曲线陡峭，概念多（Zone、租户、资源池、Unit 等）
文档虽然改善了，但部分内容仍不够详细，社区答疑响应慢
部署和运维复杂度高，小团队建议用 OCP（OceanBase Cloud Platform）
社区版功能有阉割，部分企业级功能需要商业版
对硬件资源要求高，不适合小规模场景

四、openGauss：PostgreSQL 的中国力量

4.1 架构概览

openGauss 是华为基于 PostgreSQL 9.2 内核深度改造的数据库，但经过多年发展，已经和上游 PostgreSQL 有了相当大的差异。

核心增强：

存储引擎：增加了 Ustore（In-place Update）引擎，减少表膨胀
高可用：内置流复制 + Paxos 一致性协议（企业版）
AI 调优：X-Tuner 智能参数调优、AI 查询时间预测
安全增强：支持全密态计算、数据脱敏、行级访问控制

openGauss 主节点通过 WAL 流复制到两个备节点 openGauss 主节点通过 WAL 流复制到两个备节点

4.2 PostgreSQL 兼容性

openGauss 兼容 PostgreSQL 的大部分 SQL 语法和客户端协议，但有几点需要注意：

默认端口是 5432（和 PG 一样）
支持 libpq 协议，psycopg2、JDBC 等 PG 驱动可以直接用
部分 PostgreSQL 扩展不能直接安装（因为内核版本差异）
支持 MySQL 兼容模式（dolphin 插件），可以执行部分 MySQL 语法

SQL

1-- openGauss 支持的 PG 语法示例
2CREATE TABLE users (
3    id SERIAL PRIMARY KEY,
4    name VARCHAR(100),
5    data JSONB,
6    tags TEXT[],
7    created_at TIMESTAMPTZ DEFAULT NOW()
8);
9
10-- JSONB 查询
11SELECT * FROM users WHERE data->>'role' = 'admin';
12
13-- 数组查询
14SELECT * FROM users WHERE 'dba' = ANY(tags);

4.3 部署实战：单机快速上手

openGauss 的单机部署非常简单，特别适合快速评估。

方式一：Docker 快速体验

Bash

1docker run --name opengauss \
2  --privileged=true \
3  -d \
4  -e GS_PASSWORD=MyP@ssw0rd \
5  -p 5432:5432 \
6  enmotech/opengauss:latest
7
8# 连接
9docker exec -it opengauss gsql -d postgres -U gaussdb -W MyP@ssw0rd

方式二：企业版离线安装

Bash

1# 1. 创建用户
2groupadd dbgrp
3useradd -g dbgrp -m omm
4
5# 2. 解压安装包
6tar -xf openGauss-5.0.0-CentOS-64bit-all.tar.gz
7tar -xf openGauss-5.0.0-CentOS-64bit-om.tar.gz
8
9# 3. 准备 XML 配置文件
10cat > cluster_config.xml << 'XMLEOF'
11<?xml version="1.0" encoding="UTF-8"?>
12<ROOT>
13    <CLUSTER>
14        <PARAM name="clusterName" value="opengauss_cluster"/>
15        <PARAM name="nodeNames" value="node1"/>
16        <PARAM name="backIp1s" value="10.0.1.1"/>
17        <PARAM name="gaussdbAppPath" value="/opt/openGauss/app"/>
18        <PARAM name="gaussdbLogPath" value="/var/log/openGauss"/>
19        <PARAM name="gaussdbToolPath" value="/opt/openGauss/tool"/>
20        <PARAM name="corePath" value="/opt/openGauss/core"/>
21    </CLUSTER>
22    <DEVICELIST>
23        <DEVICE sn="node1">
24            <PARAM name="name" value="node1"/>
25            <PARAM name="backIp1" value="10.0.1.1"/>
26            <PARAM name="sshIp1" value="10.0.1.1"/>
27            <PARAM name="dataNum" value="1"/>
28            <PARAM name="dataPortBase" value="5432"/>
29            <PARAM name="dataNode1" value="/opt/openGauss/data/dn"/>
30        </DEVICE>
31    </DEVICELIST>
32</ROOT>
33XMLEOF
34
35# 4. 预安装
36cd /opt/software/openGauss
37./script/gs_preinstall -U omm -G dbgrp -X /opt/software/cluster_config.xml
38
39# 5. 安装
40su - omm
41gs_install -X /opt/software/cluster_config.xml
42
43# 6. 启动
44gs_om -t start
45
46# 7. 验证
47gsql -d postgres -p 5432 -r

4.4 AI 调优：X-Tuner

openGauss 最有意思的特性之一是 AI 驱动的数据库调优。X-Tuner 是一个基于强化学习的参数调优工具：

Bash

1# 安装 X-Tuner
2pip install openGauss-xtuner
3
4# 运行调优
5gs_xtuner tune \
6  -f tuner_config.json \
7  --db-name postgres \
8  --db-user omm \
9  --host 127.0.0.1 \
10  --host-user omm \
11  --port 5432

X-Tuner 会自动采集数据库的负载特征，然后通过强化学习算法（基于 DDPG）找到最优的参数组合。实测下来，对于 shared_buffers、work_mem、effective_cache_size 等参数的调优效果还是有的，某些场景能带来 10-20% 的性能提升。

不过说实话，这个功能目前还比较初级，不能完全替代有经验的 DBA。当个辅助工具用还行。

4.5 openGauss 优缺点总结

优势：

基于 PostgreSQL 生态，SQL 功能丰富（JSONB、CTE、窗口函数等）
华为主导，有强大的商业支持
AI 调优等创新功能，差异化竞争
单机部署简单，上手快
Ustore 引擎解决了 PG 的表膨胀问题
安全特性丰富（国密算法、全密态等），适合政务场景

劣势：

社区相对较小，第三方资源少
与上游 PostgreSQL 的生态兼容性不是 100%
企业级功能（如 Paxos HA）需要商业订阅
分布式能力需要依赖 ShardingSphere 等中间件
文档偏官方化，实战类内容少

五、三大数据库横向对比

5.1 核心参数对比表

对比项	TiDB	OceanBase	openGauss
架构类型	存算分离（TiDB + TiKV）	存算一体（OBServer）	单机/主备
协议兼容	MySQL 5.7/8.0	MySQL + Oracle 双模	PostgreSQL
共识协议	Raft	Paxos	流复制 / Paxos（企业版）
最低资源	3 节点，各 8C16G	3 节点，各 8C16G	单节点 4C8G
高可用	Raft 多副本	Zone 级 Paxos	主备流复制
HTAP 能力	TiFlash 列存	有，但不成熟	无原生支持
开源协议	Apache 2.0	MulanPubL-2.0	MulanPSL-2.0
GitHub Star	36k+	8k+	6k+
社区活跃度	高	中	中偏低
典型客户	字节、美团、小红书	蚂蚁、建行、招行	邮储、电力、政务
存储引擎	RocksDB (TiKV)	LSM-Tree	Astore / Ustore
分布式事务	乐观/悲观锁	两阶段提交	需中间件

5.2 部署复杂度对比

1简单 ◄────────────────────────────► 复杂
2
3openGauss(单机)  TiDB(TiUP)  OceanBase(OBD)  openGauss(集群)
4     ★              ★★           ★★★              ★★★★

openGauss 单机：Docker 一行命令搞定，5 分钟上手
TiDB：TiUP 工具链成熟，拓扑文件写好后一键部署，约 15-30 分钟
OceanBase：OBD 可以用但有坑，Bootstrap 阶段容易出问题，约 30-60 分钟
openGauss 集群：需要手动配置流复制或借助第三方工具，复杂度较高

六、性能对比参考

声明：以下数据来自实验环境测试，仅供参考。不同硬件、不同配置、不同数据量下结果会有较大差异。生产环境请以实际 POC 测试结果为准。

6.1 测试环境

YAML

1CPU:    Intel Xeon Gold 6248R × 2 (48C)
2内存:   256GB DDR4 ECC
3磁盘:   NVMe SSD 3.2TB × 2
4网络:   25Gbps
5OS:     CentOS 7.9 / openEuler 22.03

每款数据库分配 3 台同规格服务器。

6.2 Sysbench OLTP 测试

测试场景：oltp_read_write，10 张表，每表 1000 万行。

并发数	TiDB (TPS)	OceanBase (TPS)	openGauss (TPS)
16	3,200	3,800	4,500
64	9,800	12,500	11,200
128	14,500	18,200	13,800
256	16,800	21,500	14,200
512	17,200	22,800	13,500

分析：

低并发下，openGauss 单机性能最好（省去了分布式协调开销）
高并发下，OceanBase 表现最强，优化器和存储引擎针对高并发场景做了大量优化
TiDB 在高并发下表现稳定，但绝对值略低于 OceanBase
openGauss 在 256 并发以上开始出现性能拐点，受限于单机资源

6.3 TPC-C 参考数据

数据库	TPC-C 成绩 (tpmC)	备注
OceanBase	7.07 亿（2022 年世界纪录）	1554 节点
TiDB	未公开官方 TPC-C 数据	社区有非官方测试
openGauss	150 万 (tpmC)	单机测试

OceanBase 的 TPC-C 成绩虽然惊人，但请注意它用了 1554 个节点。单节点性能和分布式堆机器的性能是两回事，不能简单类比。

6.4 HTAP 混合负载

针对 HTAP 场景，我在 TiDB 上做了一组对比测试：

SQL

1-- OLTP: 持续进行点查和小事务
2-- OLAP: 同时跑复杂分析查询
3
4SELECT 
5    l_returnflag,
6    l_linestatus,
7    SUM(l_quantity) as sum_qty,
8    SUM(l_extendedprice) as sum_base_price,
9    AVG(l_quantity) as avg_qty,
10    COUNT(*) as count_order
11FROM lineitem
12WHERE l_shipdate <= DATE '2025-12-01' - INTERVAL '90' DAY
13GROUP BY l_returnflag, l_linestatus
14ORDER BY l_returnflag, l_linestatus;

场景	TiDB (无 TiFlash)	TiDB (有 TiFlash)	OceanBase	openGauss
OLAP 查询耗时	45s	3.2s	28s	38s
OLTP 性能影响	-35%	-5%	-25%	-40%

TiFlash 在 HTAP 场景下的优势非常明显：OLAP 查询速度提升 14 倍，同时对 OLTP 的影响从 35% 降到了 5%。这就是存算分离 + 列式引擎的价值。

七、场景化选型指南

选数据库没有 "最好" 的，只有 "最合适" 的。以下是我的建议：

7.1 互联网 / HTAP 场景 → TiDB

适合你如果：

业务增长快，需要弹性扩缩容
有混合负载需求（白天跑交易，晚上跑报表）
团队熟悉 MySQL，希望低成本迁移
不想维护 MySQL 分库分表

典型案例： 电商订单系统、实时数据分析平台、游戏用户数据、SaaS 多租户

TiDB 选型决策树

你的业务有 MySQL 分库分表？ → Yes → TiDB 你需要实时 OLAP？ → Yes → TiDB + TiFlash
数据量 < 500GB 且不需要扩展？ → No → 考虑其他方案

7.2 金融 / Oracle 迁移 → OceanBase

适合你如果：

对数据一致性要求极高（RPO = 0）
正在从 Oracle 迁移，有大量 PL/SQL 代码
需要多租户资源隔离
业务在金融、保险等强监管行业

典型案例： 银行核心系统、证券交易、保险理赔、支付清算

OceanBase 选型决策树

你的核心系统跑在 Oracle 上？ → Yes → OceanBase Oracle 模式需要金融级 RPO=0？ → Yes → OceanBase 不确定用 MySQL 还是 Oracle 模式？ → MySQL 模式起步

7.3 PostgreSQL 生态 / 政务 → openGauss

适合你如果：

团队熟悉 PostgreSQL
项目在政务、电力等对国产化要求严格的行业
业务以单机或小规模集群为主
需要高级 SQL 功能（JSONB、数组、CTE 等）

典型案例： 政务 OA 系统、电力调度系统、高校管理系统、中小规模业务

openGauss 选型决策树

你的团队熟悉 PostgreSQL？ → Yes → openGauss 政务信创项目要求华为生态？ → Yes → openGauss 需要分布式能力？ → Yes → openGauss + ShardingSphere

八、从 Oracle/MySQL 迁移注意事项

8.1 Oracle 迁移路径

迁移到 OceanBase（推荐）：

通过 OMS 将 Oracle 迁移到 OceanBase Oracle 模式通过 OMS 将 Oracle 迁移到 OceanBase Oracle 模式

OceanBase 提供了 OMS 迁移工具，支持：

结构迁移（DDL 转换）
全量数据迁移
增量数据同步（基于 LogMiner）
数据校验

迁移到 openGauss：

通过 ora2og 将 Oracle 迁移到 openGauss 通过 ora2og 将 Oracle 迁移到 openGauss

openGauss 社区提供了 ora2og 迁移工具，但成熟度不如 OMS。复杂的 PL/SQL 代码需要手动改造。

8.2 MySQL 迁移路径

迁移到 TiDB（推荐）：

通过 TiDB Data Migration 将 MySQL 迁移到 TiDB 通过 TiDB Data Migration 将 MySQL 迁移到 TiDB

TiDB DM 支持：

全量 + 增量迁移
多个 MySQL 实例合并迁移到一个 TiDB 集群
分库分表合并
Binlog 实时同步

Bash

1# DM 迁移任务示例
2tiup dmctl --master-addr=10.0.1.1:8261 \
3  start-task task.yaml

迁移到 OceanBase：

通过 OMS 将 MySQL 迁移到 OceanBase MySQL 模式通过 OMS 将 MySQL 迁移到 OceanBase MySQL 模式

8.3 迁移通用建议

先跑 POC：在测试环境跑一个月，覆盖所有核心业务场景
SQL 兼容性扫描：用各数据库提供的兼容性检查工具，提前发现不兼容的 SQL
灰度切换：先迁移非核心系统，积累经验后再切核心系统
双写过渡：迁移期间可以双写新旧数据库，确保数据一致
回退方案：一定要有明确的回退方案，不要赌不回退

九、实用运维命令速查

9.1 TiDB 常用命令

Bash

1# 查看集群状态
2tiup cluster display tidb-test
3
4# 扩容 TiKV 节点
5tiup cluster scale-out tidb-test scale-out.yaml
6
7# 缩容节点
8tiup cluster scale-in tidb-test --node 10.0.1.4:20160
9
10# 升级版本
11tiup cluster upgrade tidb-test v7.6.0
12
13# 查看慢查询
14SELECT * FROM information_schema.slow_query 
15WHERE time > '2026-05-06 00:00:00' 
16ORDER BY query_time DESC LIMIT 10;

9.2 OceanBase 常用命令

Bash

1# 查看集群状态
2obclient -h 10.0.1.1 -P 2881 -u root@sys -e "SELECT * FROM oceanbase.DBA_OB_SERVERS;"
3
4# 查看租户
5SELECT * FROM oceanbase.DBA_OB_TENANTS;
6
7# 查看 Zone 状态
8SELECT * FROM oceanbase.DBA_OB_ZONES;
9
10# 合并管理（Major Compaction）
11ALTER SYSTEM MAJOR FREEZE;
12SELECT * FROM oceanbase.CDB_OB_MAJOR_COMPACTION;
13
14# 租户级慢查询
15SELECT * FROM oceanbase.GV$OB_SQL_AUDIT 
16WHERE elapsed_time > 1000000 
17ORDER BY elapsed_time DESC LIMIT 10;

9.3 openGauss 常用命令

Bash

1# 查看实例状态
2gs_om -t status --detail
3
4# 查看连接信息
5gsql -d postgres -p 5432 -c "SELECT * FROM pg_stat_activity;"
6
7# 性能视图
8SELECT * FROM dbe_perf.statement ORDER BY total_time DESC LIMIT 10;
9
10# 备份
11gs_basebackup -D /backup/full -p 5432
12
13# 健康检查
14gs_check -i CheckAll -L

十、写在最后

三款数据库我都在测试环境深度使用过，说点主观感受：

TiDB 给我的感觉最 "互联网"，工具链好用、社区活跃、文档齐全。如果你是互联网公司的 DBA，TiDB 的上手体验是最好的。
OceanBase 给我的感觉最 "硬核"，架构设计精妙，性能强悍，但学习成本也是最高的。如果你是金融行业的 DBA，OceanBase 值得深入研究。
openGauss 给我的感觉最 "朴实"，基于 PG 的底子很好，单机性能不错，适合不需要分布式的场景。如果你是 PG 用户或者在政务行业，openGauss 是个稳妥的选择。

最后一句话：不要为了国产化而国产化，要为了解决实际问题而选型。信创是大趋势没错，但选什么数据库还是要回到业务本身。先搞清楚自己的数据量、并发量、一致性要求、团队技术栈，再来选数据库，才是正确的姿势。

如果你在做数据库选型，欢迎在评论区交流。我后续也会写单独的深度文章，分别介绍 TiDB、OceanBase、openGauss 的生产环境调优经验。

参考资料：

TiDB 官方文档

OceanBase 官方文档

openGauss 官方文档

TPC-C 官方排名

信创产业发展白皮书 2025

本章小结

本章介绍了以下核心内容：

写在前面
一、为什么要关注国产数据库？
二、TiDB：分布式 NewSQL 的标杆
三、OceanBase：金融级分布式数据库
四、openGauss：PostgreSQL 的中国力量
五、三大数据库横向对比
六、性能对比参考
七、场景化选型指南
7.2 金融 / Oracle 迁移 → OceanBase
7.3 PostgreSQL 生态 / 政务 → openGauss
八、从 Oracle/MySQL 迁移注意事项
九、实用运维命令速查
十、写在最后

DBA 实战课程系统学习 Oracle DBA查看完整课程

写在前面

如果你是一线 DBA，或者正在做技术选型，你一定绑不开这三个名字：

TiDB — PingCAP 出品，分布式 NewSQL 的代表
OceanBase — 蚂蚁集团出品，金融级分布式数据库
openGauss — 华为出品，基于 PostgreSQL 的增强型数据库

我从去年开始陆续在测试环境把这三款数据库都跑了一遍，今天这篇文章就把我的实际体验分享出来。不吹不黑，用数据和部署日志说话。

一、为什么要关注国产数据库？

1.1 政策驱动

1.2 技术已经成熟

五年前你可能还会说 "国产数据库不靠谱"，但今天情况完全不同了：

TiDB 已经在头部互联网公司的核心交易系统上线
OceanBase 连续多年打破 TPC-C 世界纪录
openGauss 在政务、电力等行业有大量落地案例

说白了，现在不是 "能不能用" 的问题，而是 "选哪个" 的问题。

1.3 Oracle/MySQL 迁移压力

二、TiDB：分布式 NewSQL 的标杆

2.1 架构概览

TiDB 的架构设计非常清晰，核心由三个组件构成：

TiDB Server、TiKV 与 PD 的架构关系 TiDB Server、TiKV 与 PD 的架构关系

关键设计点：

TiDB Server：负责 SQL 解析和执行，本身不存数据，天然支持水平扩展。你可以理解为它就是一个 "计算节点"。
TiKV：底层存储引擎，数据按 Region 分片，每个 Region 默认 96MB。Region 之间通过 Raft 协议保证强一致性。
PD (Placement Driver)：集群的 "大脑"，负责 Region 调度、TSO（全局时间戳）分配和元数据管理。
TiFlash（可选）：列式存储引擎，实时同步 TiKV 的数据，专门用于 OLAP 分析查询。这就是 TiDB 所谓的 HTAP 能力。

2.2 MySQL 兼容性

TiDB 兼容 MySQL 5.7/8.0 协议，大部分 MySQL 客户端和 ORM 框架可以直接连。但要注意几个坑：

自增 ID 不连续：TiDB 的自增 ID 是分段分配的，不保证连续递增。如果你的业务依赖自增 ID 的连续性，需要提前改造。
事务大小限制：默认单个事务的 KV 对数量限制在 txn-total-size-limit = 100MB，大批量 INSERT 需要分批处理。
部分 MySQL 函数不支持：比如 CREATE PROCEDURE 的支持是实验性的，存储过程重度用户需要留意。
外键约束：从 v6.6 开始支持，但建议在分布式场景下慎用。

实际迁移中，大概 80-90% 的 MySQL 应用可以平滑迁移到 TiDB，剩下的需要做一些改造。

2.3 部署实战：TiUP 一键拉起

TiDB 的部署体验是三者中最丝滑的，核心工具是 TiUP。

第一步：安装 TiUP

Bash

1curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
2source ~/.bashrc

第二步：准备拓扑文件

YAML

1# topology.yaml
2
3> **本章目标**：掌握本章核心知识点
4> **前置要求**：完成前序章节学习
5> **预计时长**：60 分钟
6
7global:
8  user: "tidb"
9  ssh_port: 22
10  deploy_dir: "/tidb-deploy"
11  data_dir: "/tidb-data"
12
13server_configs:
14  tidb:
15    log.slow-threshold: 300
16  tikv:
17    readpool.storage.use-unified-pool: true
18    readpool.coprocessor.use-unified-pool: true
19  pd:
20    replication.location-labels: ["host"]
21
22tidb_servers:
23  - host: 10.0.1.1
24  - host: 10.0.1.2
25
26tikv_servers:
27  - host: 10.0.1.1
28  - host: 10.0.1.2
29  - host: 10.0.1.3
30
31pd_servers:
32  - host: 10.0.1.1
33  - host: 10.0.1.2
34  - host: 10.0.1.3
35
36monitoring_servers:
37  - host: 10.0.1.1
38
39grafana_servers:
40  - host: 10.0.1.1

第三步：一键部署

Bash

1tiup cluster deploy tidb-test v7.6.0 ./topology.yaml --user root -p
2tiup cluster start tidb-test

部署完成后，TiUP 会自动帮你配好 Prometheus + Grafana 监控，开箱即用。这一点真的要给好评。

第四步：验证连接

Bash

1mysql -h 10.0.1.1 -P 4000 -u root

没错，直接用 MySQL 客户端连，端口默认是 4000。

2.4 HTAP 能力：TiFlash

TiFlash 是 TiDB 的杀手锏之一。你可以对某张表开启 TiFlash 副本：

SQL

1ALTER TABLE orders SET TIFLASH REPLICA 1;

实际测试中，同一张 5000 万行的订单表：

走 TiKV 做 SELECT COUNT(*) ... GROUP BY 需要 12 秒
走 TiFlash 只需要 0.8 秒

这就是列存的威力。

2.5 TiDB 优缺点总结

优势：

水平扩展能力强，加节点就能线性扩容
MySQL 协议兼容，迁移成本相对低
社区活跃，GitHub 36k+ Star，文档齐全
HTAP 能力成熟，一套系统搞定 TP + AP
TiUP 工具链完善，运维体验好

劣势：

资源消耗大，最小部署需要 3 台服务器（生产环境建议 6 台以上）
调优复杂，Raft Region 调度、GC 等参数需要经验
单机性能不如 MySQL，不适合小规模业务
学习曲线较陡（虽然用 MySQL 协议，但底层逻辑完全不同）

三、OceanBase：金融级分布式数据库

3.1 架构概览

OceanBase 采用 Shared-Nothing 架构，核心概念包括：

OceanBase 三 Zone 与 OBProxy 架构 OceanBase 三 Zone 与 OBProxy 架构

关键设计点：

Zone：OceanBase 的核心高可用单元。一般部署 3 个 Zone，分布在不同机房或可用区。数据在 Zone 之间通过 Paxos 协议 保持强一致。
OBServer：每个 Zone 里的数据库服务进程，集计算和存储于一体。
OBProxy：SQL 路由代理，负责将请求转发到正确的 OBServer。
租户（Tenant）：OceanBase 的资源隔离单元，类似 "数据库实例"。一个集群可以创建多个租户，每个租户有独立的 CPU、内存配额。

3.2 MySQL + Oracle 双兼容

OceanBase 最大的特色之一是同时兼容 MySQL 和 Oracle 两套语法模式：

SQL

1-- 创建 MySQL 模式租户
2CREATE TENANT mysql_tenant 
3  RESOURCE_POOL_LIST = ('pool_mysql')
4  SET ob_compatibility_mode = 'mysql';
5
6-- 创建 Oracle 模式租户
7CREATE TENANT oracle_tenant 
8  RESOURCE_POOL_LIST = ('pool_oracle')  
9  SET ob_compatibility_mode = 'oracle';

Oracle 兼容模式支持：

PL/SQL 语法（包括包、存储过程、触发器）
Oracle 数据类型（NUMBER、VARCHAR2、DATE 等）
Oracle 内置函数（NVL、DECODE、TO_CHAR 等）
DBMS_OUTPUT 等常用包
同义词（SYNONYM）和序列（SEQUENCE）

对于 Oracle 迁移来说，这个功能简直是救命稻草。实际测试中，大约 70-80% 的 Oracle PL/SQL 代码可以在 OceanBase Oracle 模式下直接运行。

3.3 部署实战：OBD 工具

OceanBase 的部署工具是 OBD (OceanBase Deployer)。

第一步：安装 OBD

Bash

1# CentOS/RHEL
2sudo yum install -y yum-utils
3sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo
4sudo yum install -y ob-deploy
5
6# 或者用 rpm 包
7rpm -ivh ob-deploy-*.rpm

第二步：单机快速部署（测试环境）

Bash

1# 单机 all-in-one 部署，适合学习和测试
2obd demo

这个命令会在本地拉起一个最小化的 OceanBase 实例，包含 1 个 OBServer + 1 个 OBProxy。

第三步：集群部署（生产环境）

YAML

1# mini-distributed.yaml
2oceanbase-ce:
3  servers:
4    - name: server1
5      ip: 10.0.1.1
6    - name: server2
7      ip: 10.0.1.2
8    - name: server3
9      ip: 10.0.1.3
10  global:
11    devname: eth0
12    memory_limit: 16G
13    datafile_size: 100G
14    log_disk_size: 100G
15    cpu_count: 16
16    mysql_port: 2881
17    rpc_port: 2882
18    home_path: /home/admin/oceanbase
19    zone: zone1
20  server1:
21    zone: zone1
22  server2:
23    zone: zone2
24  server3:
25    zone: zone3
26
27obproxy-ce:
28  servers:
29    - 10.0.1.1
30  global:
31    listen_port: 2883
32    prometheus_listen_port: 2884
33    home_path: /home/admin/obproxy
34    obproxy_sys_password: ******
35    observer_sys_password: ******

Bash

1obd cluster deploy ob-test -c mini-distributed.yaml
2obd cluster start ob-test

注意事项：

OceanBase 对内存要求较高，单个 OBServer 建议至少 16GB 内存
启动过程比较慢（Bootstrap 阶段需要 2-5 分钟），不要以为卡死了就 Ctrl+C
第一次登录用 root@sys 租户：mysql -h 10.0.1.1 -P 2881 -u root@sys

3.4 Zone 级高可用

OceanBase 的高可用设计非常硬核：

RPO = 0：基于 Paxos 协议，只要多数派 Zone 存活，数据零丢失
RTO < 30 秒：节点故障后，Paxos 自动选主，业务恢复时间在 30 秒以内
三地五中心：支持跨城部署，在城市级别的灾难下也能保证数据安全

蚂蚁每年双十一用的就是 OceanBase，金融级可靠性不是吹的。

3.5 OceanBase 优缺点总结

优势：

金融级高可靠，Paxos 强一致，RPO = 0
MySQL + Oracle 双兼容，Oracle 迁移友好
多租户资源隔离，一套集群服务多个业务
压缩率高，LSM-Tree 存储引擎自带压缩，实测存储空间约为 MySQL 的 1/3
TPC-C 世界纪录保持者，性能过硬

劣势：

学习曲线陡峭，概念多（Zone、租户、资源池、Unit 等）
文档虽然改善了，但部分内容仍不够详细，社区答疑响应慢
部署和运维复杂度高，小团队建议用 OCP（OceanBase Cloud Platform）
社区版功能有阉割，部分企业级功能需要商业版
对硬件资源要求高，不适合小规模场景

四、openGauss：PostgreSQL 的中国力量

4.1 架构概览

openGauss 是华为基于 PostgreSQL 9.2 内核深度改造的数据库，但经过多年发展，已经和上游 PostgreSQL 有了相当大的差异。

核心增强：

存储引擎：增加了 Ustore（In-place Update）引擎，减少表膨胀
高可用：内置流复制 + Paxos 一致性协议（企业版）
AI 调优：X-Tuner 智能参数调优、AI 查询时间预测
安全增强：支持全密态计算、数据脱敏、行级访问控制

openGauss 主节点通过 WAL 流复制到两个备节点 openGauss 主节点通过 WAL 流复制到两个备节点

4.2 PostgreSQL 兼容性

openGauss 兼容 PostgreSQL 的大部分 SQL 语法和客户端协议，但有几点需要注意：

默认端口是 5432（和 PG 一样）
支持 libpq 协议，psycopg2、JDBC 等 PG 驱动可以直接用
部分 PostgreSQL 扩展不能直接安装（因为内核版本差异）
支持 MySQL 兼容模式（dolphin 插件），可以执行部分 MySQL 语法

SQL

1-- openGauss 支持的 PG 语法示例
2CREATE TABLE users (
3    id SERIAL PRIMARY KEY,
4    name VARCHAR(100),
5    data JSONB,
6    tags TEXT[],
7    created_at TIMESTAMPTZ DEFAULT NOW()
8);
9
10-- JSONB 查询
11SELECT * FROM users WHERE data->>'role' = 'admin';
12
13-- 数组查询
14SELECT * FROM users WHERE 'dba' = ANY(tags);

4.3 部署实战：单机快速上手

openGauss 的单机部署非常简单，特别适合快速评估。

方式一：Docker 快速体验

Bash

1docker run --name opengauss \
2  --privileged=true \
3  -d \
4  -e GS_PASSWORD=MyP@ssw0rd \
5  -p 5432:5432 \
6  enmotech/opengauss:latest
7
8# 连接
9docker exec -it opengauss gsql -d postgres -U gaussdb -W MyP@ssw0rd

方式二：企业版离线安装

Bash

1# 1. 创建用户
2groupadd dbgrp
3useradd -g dbgrp -m omm
4
5# 2. 解压安装包
6tar -xf openGauss-5.0.0-CentOS-64bit-all.tar.gz
7tar -xf openGauss-5.0.0-CentOS-64bit-om.tar.gz
8
9# 3. 准备 XML 配置文件
10cat > cluster_config.xml << 'XMLEOF'
11<?xml version="1.0" encoding="UTF-8"?>
12<ROOT>
13    <CLUSTER>
14        <PARAM name="clusterName" value="opengauss_cluster"/>
15        <PARAM name="nodeNames" value="node1"/>
16        <PARAM name="backIp1s" value="10.0.1.1"/>
17        <PARAM name="gaussdbAppPath" value="/opt/openGauss/app"/>
18        <PARAM name="gaussdbLogPath" value="/var/log/openGauss"/>
19        <PARAM name="gaussdbToolPath" value="/opt/openGauss/tool"/>
20        <PARAM name="corePath" value="/opt/openGauss/core"/>
21    </CLUSTER>
22    <DEVICELIST>
23        <DEVICE sn="node1">
24            <PARAM name="name" value="node1"/>
25            <PARAM name="backIp1" value="10.0.1.1"/>
26            <PARAM name="sshIp1" value="10.0.1.1"/>
27            <PARAM name="dataNum" value="1"/>
28            <PARAM name="dataPortBase" value="5432"/>
29            <PARAM name="dataNode1" value="/opt/openGauss/data/dn"/>
30        </DEVICE>
31    </DEVICELIST>
32</ROOT>
33XMLEOF
34
35# 4. 预安装
36cd /opt/software/openGauss
37./script/gs_preinstall -U omm -G dbgrp -X /opt/software/cluster_config.xml
38
39# 5. 安装
40su - omm
41gs_install -X /opt/software/cluster_config.xml
42
43# 6. 启动
44gs_om -t start
45
46# 7. 验证
47gsql -d postgres -p 5432 -r

4.4 AI 调优：X-Tuner

openGauss 最有意思的特性之一是 AI 驱动的数据库调优。X-Tuner 是一个基于强化学习的参数调优工具：

Bash

1# 安装 X-Tuner
2pip install openGauss-xtuner
3
4# 运行调优
5gs_xtuner tune \
6  -f tuner_config.json \
7  --db-name postgres \
8  --db-user omm \
9  --host 127.0.0.1 \
10  --host-user omm \
11  --port 5432

不过说实话，这个功能目前还比较初级，不能完全替代有经验的 DBA。当个辅助工具用还行。

4.5 openGauss 优缺点总结

优势：

基于 PostgreSQL 生态，SQL 功能丰富（JSONB、CTE、窗口函数等）
华为主导，有强大的商业支持
AI 调优等创新功能，差异化竞争
单机部署简单，上手快
Ustore 引擎解决了 PG 的表膨胀问题
安全特性丰富（国密算法、全密态等），适合政务场景

劣势：

社区相对较小，第三方资源少
与上游 PostgreSQL 的生态兼容性不是 100%
企业级功能（如 Paxos HA）需要商业订阅
分布式能力需要依赖 ShardingSphere 等中间件
文档偏官方化，实战类内容少

五、三大数据库横向对比

5.1 核心参数对比表

对比项	TiDB	OceanBase	openGauss
架构类型	存算分离（TiDB + TiKV）	存算一体（OBServer）	单机/主备
协议兼容	MySQL 5.7/8.0	MySQL + Oracle 双模	PostgreSQL
共识协议	Raft	Paxos	流复制 / Paxos（企业版）
最低资源	3 节点，各 8C16G	3 节点，各 8C16G	单节点 4C8G
高可用	Raft 多副本	Zone 级 Paxos	主备流复制
HTAP 能力	TiFlash 列存	有，但不成熟	无原生支持
开源协议	Apache 2.0	MulanPubL-2.0	MulanPSL-2.0
GitHub Star	36k+	8k+	6k+
社区活跃度	高	中	中偏低
典型客户	字节、美团、小红书	蚂蚁、建行、招行	邮储、电力、政务
存储引擎	RocksDB (TiKV)	LSM-Tree	Astore / Ustore
分布式事务	乐观/悲观锁	两阶段提交	需中间件

5.2 部署复杂度对比

1简单 ◄────────────────────────────► 复杂
2
3openGauss(单机)  TiDB(TiUP)  OceanBase(OBD)  openGauss(集群)
4     ★              ★★           ★★★              ★★★★

openGauss 单机：Docker 一行命令搞定，5 分钟上手
TiDB：TiUP 工具链成熟，拓扑文件写好后一键部署，约 15-30 分钟
OceanBase：OBD 可以用但有坑，Bootstrap 阶段容易出问题，约 30-60 分钟
openGauss 集群：需要手动配置流复制或借助第三方工具，复杂度较高

六、性能对比参考

声明：以下数据来自实验环境测试，仅供参考。不同硬件、不同配置、不同数据量下结果会有较大差异。生产环境请以实际 POC 测试结果为准。

6.1 测试环境

YAML

1CPU:    Intel Xeon Gold 6248R × 2 (48C)
2内存:   256GB DDR4 ECC
3磁盘:   NVMe SSD 3.2TB × 2
4网络:   25Gbps
5OS:     CentOS 7.9 / openEuler 22.03

每款数据库分配 3 台同规格服务器。

6.2 Sysbench OLTP 测试

测试场景：oltp_read_write，10 张表，每表 1000 万行。

并发数	TiDB (TPS)	OceanBase (TPS)	openGauss (TPS)
16	3,200	3,800	4,500
64	9,800	12,500	11,200
128	14,500	18,200	13,800
256	16,800	21,500	14,200
512	17,200	22,800	13,500

分析：

低并发下，openGauss 单机性能最好（省去了分布式协调开销）
高并发下，OceanBase 表现最强，优化器和存储引擎针对高并发场景做了大量优化
TiDB 在高并发下表现稳定，但绝对值略低于 OceanBase
openGauss 在 256 并发以上开始出现性能拐点，受限于单机资源

6.3 TPC-C 参考数据

数据库	TPC-C 成绩 (tpmC)	备注
OceanBase	7.07 亿（2022 年世界纪录）	1554 节点
TiDB	未公开官方 TPC-C 数据	社区有非官方测试
openGauss	150 万 (tpmC)	单机测试

OceanBase 的 TPC-C 成绩虽然惊人，但请注意它用了 1554 个节点。单节点性能和分布式堆机器的性能是两回事，不能简单类比。

6.4 HTAP 混合负载

针对 HTAP 场景，我在 TiDB 上做了一组对比测试：

SQL

1-- OLTP: 持续进行点查和小事务
2-- OLAP: 同时跑复杂分析查询
3
4SELECT 
5    l_returnflag,
6    l_linestatus,
7    SUM(l_quantity) as sum_qty,
8    SUM(l_extendedprice) as sum_base_price,
9    AVG(l_quantity) as avg_qty,
10    COUNT(*) as count_order
11FROM lineitem
12WHERE l_shipdate <= DATE '2025-12-01' - INTERVAL '90' DAY
13GROUP BY l_returnflag, l_linestatus
14ORDER BY l_returnflag, l_linestatus;

场景	TiDB (无 TiFlash)	TiDB (有 TiFlash)	OceanBase	openGauss
OLAP 查询耗时	45s	3.2s	28s	38s
OLTP 性能影响	-35%	-5%	-25%	-40%

TiFlash 在 HTAP 场景下的优势非常明显：OLAP 查询速度提升 14 倍，同时对 OLTP 的影响从 35% 降到了 5%。这就是存算分离 + 列式引擎的价值。

七、场景化选型指南

选数据库没有 "最好" 的，只有 "最合适" 的。以下是我的建议：

7.1 互联网 / HTAP 场景 → TiDB

适合你如果：

业务增长快，需要弹性扩缩容
有混合负载需求（白天跑交易，晚上跑报表）
团队熟悉 MySQL，希望低成本迁移
不想维护 MySQL 分库分表

典型案例： 电商订单系统、实时数据分析平台、游戏用户数据、SaaS 多租户

TiDB 选型决策树

你的业务有 MySQL 分库分表？ → Yes → TiDB 你需要实时 OLAP？ → Yes → TiDB + TiFlash
数据量 < 500GB 且不需要扩展？ → No → 考虑其他方案

7.2 金融 / Oracle 迁移 → OceanBase

适合你如果：

对数据一致性要求极高（RPO = 0）
正在从 Oracle 迁移，有大量 PL/SQL 代码
需要多租户资源隔离
业务在金融、保险等强监管行业

典型案例： 银行核心系统、证券交易、保险理赔、支付清算

OceanBase 选型决策树

你的核心系统跑在 Oracle 上？ → Yes → OceanBase Oracle 模式需要金融级 RPO=0？ → Yes → OceanBase 不确定用 MySQL 还是 Oracle 模式？ → MySQL 模式起步

7.3 PostgreSQL 生态 / 政务 → openGauss

适合你如果：

团队熟悉 PostgreSQL
项目在政务、电力等对国产化要求严格的行业
业务以单机或小规模集群为主
需要高级 SQL 功能（JSONB、数组、CTE 等）

典型案例： 政务 OA 系统、电力调度系统、高校管理系统、中小规模业务

openGauss 选型决策树

你的团队熟悉 PostgreSQL？ → Yes → openGauss 政务信创项目要求华为生态？ → Yes → openGauss 需要分布式能力？ → Yes → openGauss + ShardingSphere

八、从 Oracle/MySQL 迁移注意事项

8.1 Oracle 迁移路径

迁移到 OceanBase（推荐）：

通过 OMS 将 Oracle 迁移到 OceanBase Oracle 模式通过 OMS 将 Oracle 迁移到 OceanBase Oracle 模式

OceanBase 提供了 OMS 迁移工具，支持：

结构迁移（DDL 转换）
全量数据迁移
增量数据同步（基于 LogMiner）
数据校验

迁移到 openGauss：

通过 ora2og 将 Oracle 迁移到 openGauss 通过 ora2og 将 Oracle 迁移到 openGauss

openGauss 社区提供了 ora2og 迁移工具，但成熟度不如 OMS。复杂的 PL/SQL 代码需要手动改造。

8.2 MySQL 迁移路径

迁移到 TiDB（推荐）：

通过 TiDB Data Migration 将 MySQL 迁移到 TiDB 通过 TiDB Data Migration 将 MySQL 迁移到 TiDB

TiDB DM 支持：

全量 + 增量迁移
多个 MySQL 实例合并迁移到一个 TiDB 集群
分库分表合并
Binlog 实时同步

Bash

1# DM 迁移任务示例
2tiup dmctl --master-addr=10.0.1.1:8261 \
3  start-task task.yaml

迁移到 OceanBase：

通过 OMS 将 MySQL 迁移到 OceanBase MySQL 模式通过 OMS 将 MySQL 迁移到 OceanBase MySQL 模式

8.3 迁移通用建议

先跑 POC：在测试环境跑一个月，覆盖所有核心业务场景
SQL 兼容性扫描：用各数据库提供的兼容性检查工具，提前发现不兼容的 SQL
灰度切换：先迁移非核心系统，积累经验后再切核心系统
双写过渡：迁移期间可以双写新旧数据库，确保数据一致
回退方案：一定要有明确的回退方案，不要赌不回退

九、实用运维命令速查

9.1 TiDB 常用命令

Bash

1# 查看集群状态
2tiup cluster display tidb-test
3
4# 扩容 TiKV 节点
5tiup cluster scale-out tidb-test scale-out.yaml
6
7# 缩容节点
8tiup cluster scale-in tidb-test --node 10.0.1.4:20160
9
10# 升级版本
11tiup cluster upgrade tidb-test v7.6.0
12
13# 查看慢查询
14SELECT * FROM information_schema.slow_query 
15WHERE time > '2026-05-06 00:00:00' 
16ORDER BY query_time DESC LIMIT 10;

9.2 OceanBase 常用命令

Bash

1# 查看集群状态
2obclient -h 10.0.1.1 -P 2881 -u root@sys -e "SELECT * FROM oceanbase.DBA_OB_SERVERS;"
3
4# 查看租户
5SELECT * FROM oceanbase.DBA_OB_TENANTS;
6
7# 查看 Zone 状态
8SELECT * FROM oceanbase.DBA_OB_ZONES;
9
10# 合并管理（Major Compaction）
11ALTER SYSTEM MAJOR FREEZE;
12SELECT * FROM oceanbase.CDB_OB_MAJOR_COMPACTION;
13
14# 租户级慢查询
15SELECT * FROM oceanbase.GV$OB_SQL_AUDIT 
16WHERE elapsed_time > 1000000 
17ORDER BY elapsed_time DESC LIMIT 10;

9.3 openGauss 常用命令

Bash

1# 查看实例状态
2gs_om -t status --detail
3
4# 查看连接信息
5gsql -d postgres -p 5432 -c "SELECT * FROM pg_stat_activity;"
6
7# 性能视图
8SELECT * FROM dbe_perf.statement ORDER BY total_time DESC LIMIT 10;
9
10# 备份
11gs_basebackup -D /backup/full -p 5432
12
13# 健康检查
14gs_check -i CheckAll -L

十、写在最后

三款数据库我都在测试环境深度使用过，说点主观感受：

TiDB 给我的感觉最 "互联网"，工具链好用、社区活跃、文档齐全。如果你是互联网公司的 DBA，TiDB 的上手体验是最好的。
OceanBase 给我的感觉最 "硬核"，架构设计精妙，性能强悍，但学习成本也是最高的。如果你是金融行业的 DBA，OceanBase 值得深入研究。
openGauss 给我的感觉最 "朴实"，基于 PG 的底子很好，单机性能不错，适合不需要分布式的场景。如果你是 PG 用户或者在政务行业，openGauss 是个稳妥的选择。

如果你在做数据库选型，欢迎在评论区交流。我后续也会写单独的深度文章，分别介绍 TiDB、OceanBase、openGauss 的生产环境调优经验。

参考资料：

TiDB 官方文档

OceanBase 官方文档

openGauss 官方文档

TPC-C 官方排名

信创产业发展白皮书 2025

本章小结

本章介绍了以下核心内容：

写在前面
一、为什么要关注国产数据库？
二、TiDB：分布式 NewSQL 的标杆
三、OceanBase：金融级分布式数据库
四、openGauss：PostgreSQL 的中国力量
五、三大数据库横向对比
六、性能对比参考
七、场景化选型指南
7.2 金融 / Oracle 迁移 → OceanBase
7.3 PostgreSQL 生态 / 政务 → openGauss
八、从 Oracle/MySQL 迁移注意事项
九、实用运维命令速查
十、写在最后

国产数据库横向评测：TiDB vs OceanBase vs openGauss 部署实战与性能对比 - DBA 学习之路