本文作者：付超，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 上测一遍数据库？
国产化替换走到今天，芯片和操作系统这两层的替代路径已经比较清晰了。真正难啃的是数据库这一层——它之所以难，不是因为代码量大，而是因为一个数据库要同时扛住三件事：
- 并发原语：自旋锁、Latch、原子计数器、无锁数据结构；
- MVCC 可见性：事务快照的正确性依赖于内存读写顺序；
- 崩溃恢复：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 仓库直取，无需交叉编译）
sudodnfinstallgcc icu libicu libicu-devel bison flex perl\readline readline-devel zlib zlib-devel-y第二步：拉源码、切分支
gitclone https://github.com/IvorySQL/IvorySQL.gitcdIvorySQLgitcheckout-bIVORY_REL_5_STABLE origin/IVORY_REL_5_STABLE第三步：编译安装（-j32并行编译）
./configure--prefix=/usr/local/ivorysql/ivorysql-5make-j32makeinstall第四步：初始化并启动
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 beensetto"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/-llogfile start waitingforserver to start....doneserver 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 核，意味着这台服务器的绝大部分算力在本次压测中处于闲置状态。真正的性能故事，要等下面这几个维度逐一验证之后才完整：
- 并发扩展性（最关键）——把客户端/线程提到 64/64 甚至 128/128，观察 TPS 是否随核数近似线性增长。这是衡量一台 RISC-V 服务器能否扛住生产数据库的核心指标，也是目前最值得补的一组数据。
- 内存维度——
shared_buffers从 128MB 调整到内存 25% 量级（约 64GB）。当前配置下缓存严重不足，这部分提升空间最大。 - NUMA 维度——8 个 NUMA 节点，需通过
numactl做内存绑定与进程亲和，避免跨节点访问惩罚。数据库对 NUMA 的敏感度远高于一般应用。 - 页表维度——配置 HugePages 大页，减少 TLB miss。
- WAL 与检查点——调整
wal_buffers、max_wal_size、checkpoint_*参数，优化写入路径。 - 存储维度——注意当前根分区仅 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 上已经交出了一份合格的答卷。
