玉衡数据库 性能测试报告

测试日期: 2026-08-12
测试环境: Windows 10 22631 (x64), MinGW GCC 15.2.0, 16GB内存
数据规模: 单表 5,000 行 × 4 列(编号/名称/数值/备注)
存储架构: 磁盘分页 v8(8KB页 + 64页LRU缓存 + 行索引按需加载)
测试方式: 批量测试文件 + 命令耗时显示(高精度计时)

一、测试结果

操作耗时说明
批量插入 5,000 行714.6 ms含每行校验+索引维护+每次修改后保存,平均 0.14ms/行
等值查询(走主键索引)0.1 ms当 编号 = 4321,B树 O(log n)
模糊查询(全表扫描)25.0 ms名称 像 '性能记录43%',扫描5,000行
排序 5,000 行(降序逆序)8.6 msqsort O(n log n)
分组聚合101 ms5,000组键统计
聚合计数0.7 ms计数(*)
边界等值查询0.0 ms编号 = 5000

数据文件: 330,422 字节 ≈ 42 页;重启后按需加载,内存占用恒定(64页LRU缓存,与数据总量无关)。

二、存储架构对比(全内存 v5 → 磁盘分页 v8)

指标v5(全内存)v8(磁盘分页)
内存占用随行数线性增长恒定(≤64页×8KB)
启动加载全量读盘仅读表定义+行索引,页按需加载
插入 5000 行~320ms714ms(含每次全量保存)
排序 5000 行112ms(冒泡)8.6ms(qsort)

三、索引价值验证

查询方式耗时对比
等值查询(索引列 编号)0.1 msB树 O(log n)
模糊查询(非索引列 名称)25.0 ms全表扫描 O(n)

5,000 行时索引与扫描差异约 250 倍;10 万行以上差距将放大到数量级。

四、优化记录

  1. 排序算法重写(本次):冒泡 O(n²) → qsort 索引快排 O(n log n)。逆序排序 1,341ms → 8.6ms(约155倍)。方案:预加载匹配行到内存数组,排序仅交换行号索引(不拷贝行结构)。
  2. 保存策略(页直写):保存改为按页写入缓存页 + 批量延迟落盘,5000行×2列从 88s → 0.4s。
  3. 查询不再全量落盘:仅修改数据的语句落盘,总耗时 -30%。

五、当前瓶颈分析

  1. 全量保存:每次修改语句后重写整个页区(5000行约330KB),数据量增大时保存耗时线性增长;后续可引入 WAL 增量日志
  2. 全表扫描:模糊查询/非索引条件为 O(n) 扫描,10万行级变慢;后续可扩展二级索引
  3. 分组聚合:分组键构建 O(n),可接受

六、结论

  • 玉衡数据库在 1 万行以下 的博客/小管理场景性能优秀(查询亚毫秒级,插入 0.14ms/行)
  • 磁盘分页存储落地后,内存占用恒定,大数据量可用性大幅提升
  • 索引等值查询已生效(B树),排序已优化至毫秒级
  • 后续优化方向:WAL 增量落盘、二级索引、外排序