性能基准

本页提供 Oro 与 GORM、XORM、Bun 在相同测试场景、相同数据库驱动下的性能参考。结果用于评估 ORM 层相对开销、常见业务路径表现和后续优化方向。

:::note[读取口径] 主表数据取 go test -bench 连续 10 轮的 中位数，不是单次最快值。中位数比平均值更不容易被一次系统调度、数据库缓存刷新或后台任务抖动影响，更适合做用户侧性能参考。 :::

测试环境

MySQL 和 PostgreSQL 均使用本地 duxorm 数据库。网络数据库结果会受到数据库配置、连接池、后台负载和缓存状态影响，应按相对趋势阅读。

对比库版本

Benchmark 位于独立 Go module：benchmarks/ormbench。

公平性规则

• SQLite：Oro、GORM、XORM、Bun 均使用 mattn/go-sqlite3。
• MySQL：均使用 go-sql-driver/mysql。
• PostgreSQL：均使用 pgx。
• Oro 和 GORM 均关闭默认写事务，用于高吞吐路径公平对比。
• 表结构、唯一索引、软删除字段和测试数据规模保持等价。
• 写入、查询、更新、删除都执行真实数据库操作，不是 SQL 编译 micro benchmark。
• 每个数据库执行 -count=10 -benchtime=1s -benchmem。

运行命令

SQLite 使用 mattn/go-sqlite3：

source ~/.gvm/scripts/gvm && gvm use go1.27rc1
cd benchmarks/ormbench
ORO_BENCH_DRIVER=sqlite ORO_BENCH_SQLITE_DRIVER=mattn \
  go test -bench=. -benchmem -run '^$' -benchtime=1s -count=10 -timeout=0

MySQL：

source ~/.gvm/scripts/gvm && gvm use go1.27rc1
cd benchmarks/ormbench
ORO_BENCH_DRIVER=mysql \
  go test -bench=. -benchmem -run '^$' -benchtime=1s -count=10 -timeout=0

PostgreSQL：

source ~/.gvm/scripts/gvm && gvm use go1.27rc1
cd benchmarks/ormbench
ORO_BENCH_DRIVER=pgsql \
  go test -bench=. -benchmem -run '^$' -benchtime=1s -count=10 -timeout=0

测试场景

读、更新场景会预先插入测试数据。删除场景会预先插入足够行，保证每次删除唯一行。

SQLite 结果

SQLite 结果使用同一个 CGO driver：mattn/go-sqlite3。

SQLite 分配

MySQL 结果

MySQL 结果使用 go-sql-driver/mysql。

MySQL 分配

PostgreSQL 结果

PostgreSQL 结果使用 pgx。

PostgreSQL 分配

结论

• Oro 在批量插入、按唯一索引读取、列表查询、更新和删除这些常见路径上整体处于主流 Go ORM 的第一梯队。
• SQLite 公平驱动口径下，Oro 在 CreateMany100、FirstByCode、WhereList、DeleteByCode 上表现稳定。
• MySQL 下，Oro 的批量插入、读取、更新和删除中位数优于本轮 GORM/XORM/Bun 对比结果；单条 Create 不是最快。
• PostgreSQL 下，Oro 的单条 Create、批量插入、读取、更新和删除都接近或优于主流库；WhereList 本轮 Bun 更快。
• 分配次数方面，Oro 在批量写入和查询路径上保持较低分配，说明模型扫描计划、SQL 编译缓存和批量 insert 路径已经发挥作用。

如何解读

• 看同一机器、同一数据库、同一 driver 下的相对趋势。
• 看 10 轮中位数，不看单次最快值。
• 同时看 B/op 和 allocs/op，判断 ORM 层对象分配是否健康。
• SQLite 结果必须注明 driver；纯 Go SQLite driver 和 CGO SQLite driver 的成本差异很大。
• 本页结果是基准参考，不代表所有生产环境的固定性能承诺。