去 IOE 的最后一公里：IvorySQL 5.4 × RISC-V 实测

本文作者：付超，Oracle ACE 与 PostgreSQL ACE 双认证专家，PG 分会西安用户组核心成员。

本文看点

一句话结论：IvorySQL 5.4 在 openEuler riscv64 平台上可原生编译、稳定运行，软件层面无指令集兼容性缺陷，具备作为去 IOE 替代数据库的基础条件。

而性能这一项，需要多说两句：本次压测跑出的 663 ~ 750 TPS，是在 128 核的机器上只点亮了不到 3% 算力、参数完全默认的情况下拿到的基线值。它反映的是 RISC-V 的单核算力现状，而不是这台服务器的能力上限——换句话说，差距是 CPU 给的，不是数据库拖的。

本文基于真实硬件实测，沿着一条完整的链路往下走：

• 为什么难：RISC-V 的内存模型和 x86 到底差在哪，为什么这件事对数据库是生死线
• 能不能编：源码原生编译，产出 RISC-V 原生二进制，无闭源依赖、无需打补丁
• 跑起来像不像：Oracle 兼容层预加载运行无架构异常，无段错误
• 跑得快不快：riscv64 TPS 663~750，单核等效约 187 TPS/线程，瓶颈在 CPU 不在软件

00 为什么非要在 RISC-V 上测一遍数据库？

国产化替换走到今天，芯片和操作系统这两层的替代路径已经比较清晰了。真正难啃的是数据库这一层——它之所以难，不是因为代码量大，而是因为一个数据库要同时扛住三件事：

1. 并发原语：自旋锁、Latch、原子计数器、无锁数据结构；
2. MVCC 可见性：事务快照的正确性依赖于内存读写顺序；
3. 崩溃恢复：WAL 落盘顺序一旦被乱序执行破坏，就是数据丢失。

你会发现，这三件事全都踩在同一个敏感点上——内存一致性模型。

而这恰恰是 RISC-V 和 x86 真正不一样的地方。所以，"能不能编译通过"从来不是重点，"编出来之后事务是不是还对"才是重点。

01 先讲清楚：RISC-V 上的数据库，难在哪？

在贴命令之前，先花一分钟说说这次实测的"题面"。理解了这几条，后面的测试数据才有意义。

内存模型：这台机器的"性格"和 x86 不同

x86 采用的是 TSO（Total Store Order）内存模型——它对程序员相当友好，Store-Load 之外的内存重排基本被硬件挡住了。RISC-V 默认采用的是 RVWMO（Weak Memory Ordering），允许更多种类的内存访问重排序，需要软件显式地用 fence、amo（原子内存操作）指令来划定边界。

这个差异对普通应用几乎无感，但对数据库是生死线。PostgreSQL 系的代码里散布着内存屏障、原子 CAS、自旋锁；如果这些原语在 RVWMO 下被错误翻译或错误实现，典型症状就是：偶发的事务可见性错乱、难以复现的死锁、以及在高并发下 TPS 突然"塌方"。

所以本次测试最有价值的一条结论不是"能跑"，而是"跑得不别扭"——没有出现锁竞争异常，也没有出现内存屏障相关的性能塌陷。

指令集与 ABI

实测环境的硬件能力基线是 rv64gc（UCB RISC-V + RVC 压缩指令）+ lp64d（双精度浮点 ABI），编译器 gcc 12.3.1。这是一套主流且完备的 64 位 RISC-V 组合，浮点、压缩指令、原子操作都在。

有一点算是"幸运"：RISC-V 和 x86 同为小端序。这省掉了数据库里大量与字节序相关的适配工作（想想看，如果换成大端，所有磁盘格式、WAL 记录、网络协议解析都要重新过一遍）。

工具链生态是否齐备

源码编译的第一道坎其实是依赖。实测中，构建 PostgreSQL 系数据库所需的关键依赖——gcc、libicu、bison、flex、perl、readline、zlib——在 openEuler 24.03 LTS 官方仓库里都有 riscv64 版本，直接从 dnf 拉取即可，不需要自己交叉编译任何依赖。

这条看似平淡，实际是"能不能自主构建"的分水岭。

02 环境：一台 128 核、8 NUMA 的国产服务器

先把测试机亮出来。这是一台典型的"大机器"，配置远超常规验证需求，也正因为如此，后面性能章节的解读才有了关键参照。

[highgo@openeuler-riscv64 ~]$ lscpu
Architecture:          riscv64
  Byte Order:          Little Endian
CPU(s):                128
  On-line CPU(s) list: 0-127
NUMA:
  NUMA node(s):        8
  NUMA node0 CPU(s):   0-7,16-23
  NUMA node1 CPU(s):   8-15,24-31
  NUMA node2 CPU(s):   32-39,48-55
  NUMA node3 CPU(s):   40-47,56-63
  NUMA node4 CPU(s):   64-71,80-87
  NUMA node5 CPU(s):   72-79,88-95
  NUMA node6 CPU(s):   96-103,112-119
  NUMA node7 CPU(s):   104-111,120-127

[highgo@openeuler-riscv64 ~]$ uname -a
Linux openeuler-riscv64 6.6.127-0.0.0.0.riscv64 #1 SMP Wed Jul 15 02:08:54 CST 2026
riscv64 riscv64 riscv64 GNU/Linux

[highgo@openeuler-riscv64 ~]$ free -g
               total        used        free      shared  buff/cache   available
Mem:             250           2         247           0           1         247
Swap:              0           0           0

环境体检的几条关键读数：

项目	实测值	对本次验证的意义
系统	openEuler 24.03 LTS，内核 6.6.127	国产 OS + 国产指令集，完整替换栈
CPU 拓扑	128 核 / 8 个 NUMA 节点，每节点 16 核	内存访问有跨节点代价，数据库对此极其敏感
内存	250 GB（基本全空闲）	大内存机器，默认参数会严重"浪费"
Swap	0	压测期间不存在换页抖动，数据可比性高
存储	NVMe 0.9 TB	单盘根分区仅 4.6 GB，数据目录需另挂大容量分区

这里有一条容易被忽略但很关键的信息：这台机器没有启用 Swap。这意味着压测过程中不会出现内存换页带来的 TPS 抖动，663 ~ 750 这组数字是"干净"的——但它同时也意味着，一旦内存配置失当，程序没有任何缓冲余地。

03 编译与部署：三条命令，零补丁

去 IOE 替代的首要前提，不是数据库功能多强，而是它能不能脱离闭源二进制包，在国产硬件指令集上自主编译部署。如果连源码都编不过，后面所有验证都无从谈起。

实测结果很干脆：完整源码编译一次通过，没有打任何补丁，没有改动一行源码。

第一步：装依赖（openEuler 仓库直取，无需交叉编译）

sudo dnf install gcc icu libicu libicu-devel bison flex perl \
     readline readline-devel zlib zlib-devel -y

第二步：拉源码、切分支

git clone https://github.com/IvorySQL/IvorySQL.git
cd IvorySQL
git checkout -b IVORY_REL_5_STABLE origin/IVORY_REL_5_STABLE

第三步：编译安装（-j32 并行编译）

./configure --prefix=/usr/local/ivorysql/ivorysql-5
make -j32
make install

第四步：初始化并启动

bin/initdb -D /opt/postgresql-19.3/ivorysql-5.x/data/

# 输出节选
The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
Data page checksums are enabled.                    # 数据页校验和默认开启
selecting default "shared_buffers" ... 128MB        # ← 记住这个值，第 05 节要用
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success.

bin/pg_ctl -D /opt/postgresql-19.3/ivorysql-5.x/data/ -l logfile start
waiting for server to start.... done
server started

整个过程没有任何架构相关的报错。产出的是 RISC-V 原生二进制（UCB RISC-V, RVC, double-float ABI, lp64d），不带任何闭源依赖。

部署验收项全部通过：

• ✅ initdb 数据库初始化正常
• ✅ pg_ctl 启停实例正常
• ✅ 可开启数据页校验和（checksums）
• ✅ 可配置 UTF-8 字符集
• ✅ 可接入 IvorySQL Oracle 兼容扩展库
• ✅ OS 用户与数据库超级用户映射正常
• ✅ TCP 网络连接、共享内存、NVMe 存储读写无架构异常

关键结论：不存在指令集层面的底层兼容障碍。IvorySQL 5.4 可以完全基于国产 RISC-V 硬件自主构建，不依赖闭源厂商预编译包，满足去 IOE 的基础部署诉求。

04 Oracle 兼容层：去 IOE 迁移方案的地基

Oracle 语法兼容是 IvorySQL 的核心价值，也是很多传统 Oracle 迁移去 IOE 选型时最关注的模块。如果兼容层在新架构上崩溃，那整个迁移方案就不成立。

这里有个容易被低估的技术细节：Oracle 兼容层不是一段独立的翻译脚本，而是通过扩展预加载的方式，深度挂进数据库内核的解析器、执行器和共享内存区。这意味着：

• 它和内核共用同一套内存屏障与原子原语——第 01 节提到的弱内存模型风险，在兼容层这里同样存在，甚至更集中；
• 它要在 shared_preload_libraries 阶段完成初始化，任何地址对齐、结构体布局或原子操作的架构差异，都会在实例启动时直接暴露成崩溃。

所以，兼容层能不能在新架构上干净加载并稳定运行，实际上是对数据库整体架构适配质量的一次"高压检验"。

测试中将以下三个扩展预加载到 shared_preload_libraries：

• gb18030_2022：国标编码扩展
• liboracle_parser：Oracle 语法解析器
• ivorysql_ora：Oracle 兼容核心模块

riscv64 平台验证结果：

• 扩展库可以正常加载，实例启动无异常
• SQL 执行过程中无段错误（segfault）、无崩溃
• 整套 SQL 业务用例运行期间，Oracle 解析兼容模块未出现架构相关异常

一句话：兼容层的地基是稳的。 对 Oracle 迁移选型来说，这是最有分量的一条结论——它意味着后续在 RISC-V 上做业务 SQL 全量回放，是可以期待的。

注意点：contrib 组件需手动补齐

IvorySQL 源码编译默认没有完整编译 contrib 组件，btree_gin、intarray、amcheck 等社区扩展未安装。执行 make -C contrib install 编译安装后，可解锁更多扩展能力，进一步对齐生产环境能力集。

05 性能：先看清楚，这个差距是谁给的

兼容性验证通过后，性能是绕不开的话题。这一节我们把数字拆开看。

5.1 原始数据

基于 pgbench 压测，8 客户端 / 4 线程 / 30 秒：

平台	TPS	说明
riscv64（本次实测）	663 ~ 750	shared_buffers 默认 128MB，未做调优
x86（同内核基线）	约 1600	同等压测参数

单看这两行，容易得出"RISC-V 只有 x86 一半"的结论。但把测试条件摊开，这个结论就不成立了。

5.2 把这组数字的"边界"标出来

观察维度	实测值	解读
并发线程	4 个 OS 线程	机器有 128 核，本次只动用了约 3% 的算力
单线程等效 TPS	≈ 187（750 ÷ 4）	x86 同口径约 400，比值 ≈ 0.47
shared_buffers	128 MB	占 256 GB 内存的 0.05%，几乎完全默认
NUMA	8 节点，未做绑定	存在跨节点内存访问开销
Swap	0	无换页抖动，数据可比性高
存储	NVMe	磁盘不是瓶颈

换句话说：663 ~ 750 TPS 不是"这台服务器的性能"，而是"这台服务器上 4 个 RISC-V 核 + 全默认参数下 pgbench 的性能"。它是一条基线，不是上限。

5.3 差距拆到"单核"上，性质就清楚了

把 TPS 摊到线程：riscv64 ≈ 187 TPS/线程，x86 ≈ 400 TPS/线程，比值约 0.47。

这个比值，与 RISC-V 处理器和主流 x86 服务器处理器在单核 IPC × 主频上的现实差距是同一量级。也就是说——

软件层没有"额外加价"。

这一点值得反复强调。如果 IvorySQL 在 RISC-V 上存在架构相关的性能缺陷——锁自旋异常、内存屏障失效、cache line 对齐问题、原子指令劣化——那么单核效率会比硬件差距更差，而且通常伴随 TPS 剧烈波动。

而实测的 663 ~ 750 区间平稳：没有性能塌方，没有锁竞争异常，没有内存屏障相关的退化。

这就是本节的核心结论：性能差距来自 RISC-V 单核算力，不来自数据库软件。 对于以"兼容可用"为目标的验证来说，这是比 TPS 绝对值更重要的结果。

5.4 更值得期待的是：这台机器还没被真正用起来

4 个线程 / 128 核，意味着这台服务器的绝大部分算力在本次压测中处于闲置状态。真正的性能故事，要等下面这几个维度逐一验证之后才完整：

1. 并发扩展性（最关键）——把客户端/线程提到 64/64 甚至 128/128，观察 TPS 是否随核数近似线性增长。这是衡量一台 RISC-V 服务器能否扛住生产数据库的核心指标，也是目前最值得补的一组数据。
2. 内存维度——shared_buffers 从 128MB 调整到内存 25% 量级（约 64GB）。当前配置下缓存严重不足，这部分提升空间最大。
3. NUMA 维度——8 个 NUMA 节点，需通过 numactl 做内存绑定与进程亲和，避免跨节点访问惩罚。数据库对 NUMA 的敏感度远高于一般应用。
4. 页表维度——配置 HugePages 大页，减少 TLB miss。
5. WAL 与检查点——调整 wal_buffers、max_wal_size、checkpoint_* 参数，优化写入路径。
6. 存储维度——注意当前根分区仅 4.6 GB（已用 74%），生产部署必须为数据目录规划独立的大容量 NVMe 分区。

5.5 这条基线的价值

663 ~ 750 TPS 这个数字本身不算亮眼，但它有一个不可替代的价值：它是可比对的。

同参数、同内核、跨架构，唯一的变量是 CPU。有了这条基线，后续每一次调优、每一次版本迭代，都能清楚地知道改进来自软件还是来自硬件——这比一个孤立的、经过精心调优的漂亮数字有用得多。

06 兼容性总结与落地建议

兼容性总览

评估项	兼容结论	备注
riscv64 源码编译部署	✅ 完全兼容	原生二进制，无闭源依赖，零补丁
Oracle 兼容扩展模块	✅ 可用	预加载运行无架构问题，无段错误
标准 SQL、事务、并发	✅ 完全兼容	上游内核核心特性全部生效
性能（压测基线）	✅ 无软件层损耗	差距源于单核算力，非架构缺陷
contrib 社区扩展	⚠️ 需手动编译安装	默认未构建，补齐即可

总体判断I：IvorySQL 5.4 在 RISC-V 国产硬件上软件层面兼容可用，没有发现指令集相关功能性缺陷，具备作为去 IOE 替代数据库的基础条件。

落地实践建议

1. 编译阶段：完整编译 contrib 模块

部署时执行 make -C contrib install，补齐 btree_gin、intarray、amcheck 等社区扩展，对齐商用数据库周边工具能力。

2. 性能调优：大内存服务器不要用默认参数

256GB 内存的 RISC-V 服务器，shared_buffers 默认 128MB 严重浪费资源。建议调整至内存 25% 左右，配置 HugePages 大页，并针对 8 NUMA 节点做内存绑定。同时建议补一组高并发（如 64/128 线程）压测，把设备的并发扩展能力测出来。

3. 迁移评估：Oracle 兼容模块优先做业务回放

Oracle 迁移场景，优先验证 ivorysql_ora 兼容模块对业务 SQL 的覆盖度，在 RISC-V 环境做全量业务回放测试，确认语法兼容率和性能表现后再推进生产迁移。

写在最后

去 IOE 不是简单的硬件替换，而是软硬件栈的整体适配。本次实测证明，IvorySQL 数据库可以很好地跑通 RISC-V 国产指令集——从源码编译到 Oracle 兼容层，从基础事务语义到并发压测，软件层面没有发现指令集相关的功能性缺陷。

性能这一项，我们希望被这样理解：在 128 核的机器上只用了 4 个线程、参数全默认、缓存只给了 0.05%，跑出了 663 ~ 750 TPS 且全程平稳——这不是一台 RISC-V 服务器的上限，这只是一条干净的起跑线。 差距在芯片，不在我们的代码里；而算力这块地，还空着 97%。

但生产落地，除了数据库本身，还需要配套运维工具、备份监控、中间件驱动共同完成适配。真正的去 IOE，是每一层都能自主可控、每一个环节都能真实跑通。

数据库这一层，IvorySQL 5.4 在 RISC-V 上已经交出了一份合格的答卷。