§ GreatSQL vs MySQL TPC-C 性能测试(2026.2.6)

GreatSQL TPC-C 性能测试报告

(2026 年 2 月 6 日)

GreatSQL 社区

§ 1.【文档声明】

GreatSQL 社区提醒您在阅读或使用本文档之前仔细阅读、充分理解本法律声明各条款的内容。如果您阅读或使用本文档,您的阅读或使用行为将被视为对本声明全部内容的认可。您应当通过 GreatSQL 社区网站或 GreatSQL 社区提供的其他授权通道下载、获取本文档,且仅能用于自身的合法合规的业务活动。本文档的内容视为 GreatSQL 社区的保密信息,您应当严格遵守保密义务;未经 GreatSQL 社区事先书面同意,您不得向任何第三方披露本手册内容或提供给任何第三方使用。

未经 GreatSQL 社区事先书面许可,任何单位、公司或个人不得擅自摘抄、翻译、复制本文档内容的部分或全部,不得以任何方式或途径进行替换和宣传。

由于产品版本升级、调整或其他原因,本文档内容有可能变更。GreatSQL 社区保留在没有任何通知或者提示下对本文档的内容进行修改的权利,并在 GreatSQL 社区授权通道中不定期发布更新后的用户文档。您应当实时关注用户文档的版本变更并通过 GreatSQL 社区授权渠道下载、获取最新版的用户文档。

本文档仅作为用户使用 GreatSQL 社区产品及服务的参考性指引。GreatSQL 社区在现有技术的基础上尽最大努力提供相应的介绍及操作指引,但 GreatSQL 社区在此明确声明对本文档内容的准确性、完整性、适用性、可靠性等不作任何明示或暗示的保证。任何单位、公司或个人因为下载、使用或信赖本文档而发生任何差错或经济损失的,GreatSQL 社区不承担任何法律责任。在任何情况下,GreatSQL 社区均不对任何间接性、后果性、惩戒性、偶然性、特殊性或刑罚性的损害,包括用户使用或信赖本文档而遭受的利润损失,承担责任(即使 GreatSQL 社区已被告知该等损失的可能性)。

GreatSQL 社区文档中所有内容,包括但不限于图片、架构设计、页面布局、文字描述,均由 GreatSQL 社区和/或其关联公司依法拥有其知识产权,包括但不限于商标权、专利权、著作权、商业秘密等。非经 GreatSQL 社区和/或其关联公司书面同意,任何人不得擅自使用、修改、复制、公开替换、改变、散布、发行或公开发表 GreatSQL 社区网站、产品程序或内容。此外,未经 GreatSQL 社区事先书面同意,任何人不得为了任何营销、广告、促销或其他目的使用、公布或复制 GreatSQL 社区的名称(包括但不限于单独为或以组合形式包含“GreatSQL 社区”、“GreatSQL”等 GreatSQL 社区和/或其关联公司品牌,上述品牌的附属标志及图案或任何类似公司名称、商号、商标、产品或服务名称、域名、图案标示、标志、标识或通过特定描述使第三方能够识别 GreatSQL 社区和/或其关联公司)。

如若发现本文档存在任何错误,请与 GreatSQL 社区取得直接联系。

GreatSQL 社区官网:https://greatsql.cn (opens new window)

§ 2. 概述

本次测试针对 GreatSQL 数据库基于 BenchmarkSQL 的标准 TPC-C 场景的测试。

BenchmarkSQL 是一个开源的 Java 应用程序,用于评估数据库系统在 OLTP 场景下的性能,它是符合 TPC-C 基准压力测试的工具。它最初由 HammerDB 的作者开发,后来由 Cloud V LLC 维护。

TPC-C 模型是模拟一个商品批发公司的销售模型,这个模型涵盖了一个批发公司面向客户对一系列商品进行销售的过程,这包括管理订单,管理库存,管理账号收支等操作。这些操作涉及到仓库、商品、客户、订单等概念,围绕这些概念,构造了数据表格,以及相应的数据库操作。

BenchmarkSQL 支持 MySQL(Percona、GreatSQL)、PostgreSQL、Oracle、SQL Server 等。

GreatSQL 数据库是一款 开源免费 数据库,可在普通硬件上满足金融级应用场景,具有 高可用高性能高兼容高安全 等特性,可作为 MySQL 或 Percona 的理想可选替换。

下文中提到的 ibp 是指 innodb_buffer_pool_size 参数简写。

本次测试的目的:对 GreatSQL 8.4.4-4(简称 GreatSQL)、MySQL 8.4.4(简称 MySQL)进行 TPC-C 性能测试,对比这两个数据库分别在 Intel X86 和鲲鹏 ARM 平台下不同的性能表现。

§ 3. 测试结果

从本次测试的结果来看,可以得到以下几点结论:

  1. 总体而言,GreatSQL 相对 MySQL 的性能能提升相当可观,最高可提升 42%,绝大多数并发场景下提升 10%起。

  2. GreatSQL 相对 MySQL 的性能抖动更小,tpmC 和 Latency 数据都更平稳。

  3. 在经过 8 小时连续压测后,在 Intel X86 平台下,GreatSQL 的 tpmC 降为原来的 90%;在鲲鹏 ARM 平台降为原来的 76%;在海光 X86 平台降为原来的 97%;而 MySQL 则相应分别降为原来的 50%、45%、93%;证明 GreatSQL 相对 MySQL 的稳定性更优秀可靠。

以上结论,仅基于本次测试场景的总结。

TPC-C 性能对比图如下所示:

  • Intel X86 下的对比图

GreatSQL 8.4.4-4 vs MySQL 8.4.4 Warehouses 1000 tpmC under X86

  • 鲲鹏 ARM 下的对比图

GreatSQL 8.4.4-4 vs MySQL 8.4.4 Warehouses 1000 tpmC under ARM

  • 海光 X86 下的对比图

GreatSQL 8.4.4-4 vs MySQL 8.4.4 Warehouses 1000 tpmC under Hygon

  • 测试服务器信息
Intel X86 鲲鹏 ARM 海光 X86
服务端 Dell R840
Intel 6238 x 4, 共 176 核;256Gi 内存;Nvme SSD, 3TB * 1
Huawei TS200-2280 V2
Kunpeng 920 7270Z x 2, 共 256 核;内存:2TB 内存;存储:Nvme SSD, 3TB
海光 7490
Hygon C86-4G (OPN:7490) * 2,共 256 核;内存:1.5GB;存储:Nvme SSD, 3TB
客户端 Dell R840
Intel 6238 x 4, 共 176 核;377Gi 内存;Nvme SSD, 3TB * 1
Huawei TS200-2280 V2
Kunpeng 920 7270Z x 2, 共 128 核;内存:2TB 内存;存储:Nvme SSD, 3TB
Huawei TS200-2280
Kunpeng 920 x 2, 共 128 核;内存:470G;存储:Nvme SSD, 8TB
  • 测试模式
数据库 - GreatSQL-8.4.4-4-Linux-glibc2.28
- mysql-8.4.4-linux-glibc2.17
测试工具 BenchmakrSQL 5.0
测试数据量 warehouses = 1000
测试数据库初始化后物理大小约 90GB

§ 4. 测试结果详细数据

§ 4.1 Intel X86 平台测试数据

  1. GreatSQL 8.4.4-4
  • innodbbufferpool_size=180G
  • 只启用 NUMA,未进行网卡中断绑定,双 1 模式+开 Slow Query Log + PFS
并发数 32 64 128 256 384 512 768
Round 1 203076.76 332984.55 488054.97 523207.42 479477.02 428375.64 433399.25
Round 2 203682.18 334184.79 491608.93 526782.45 493533.43 439765.11 437654.64
Round 3 203949.17 335139.59 492393.93 527856.68 493442.13 443816.97 438641.8
Round 4 204570.76 338542.96 493886.09 528678.41 494862.84 448130.37 440079.64
Round 5 205584.63 340275.05 495615.97 528902.13 497487.42 475308.81 442050.52
Avg 204172.76 336225.39 492311.98 527085.42 491760.57 447079.38 438365.17
  1. MySQL 8.4.4
  • innodbbufferpool_size=180G
  • 只启用 NUMA,未进行网卡中断绑定,双 1 模式+开 Slow Query Log + PFS
并发数 32 64 128 256 384 512 768
Round 1 156110.47 262799.11 385478.94 459070.91 442072.99 414013.36 442050.52
Round 2 162735.65 276969.75 389364.69 463834.48 455029.77 427281.38 442050.52
Round 3 162765.30 277795.95 394744.22 480302.58 464610.22 442331.82 442050.52
Round 4 163458.46 282947.50 401869.24 484189.69 471868.69 451571.49 442050.52
Round 5 164966.72 284580.72 412365.76 485594.32 472196.95 451871.54 442050.52
Avg 162007.32 277018.61 396764.57 474598.40 461155.72 437413.92 442050.52
GreatSQL 作为基数对比(并发数) 32 64 128 256 384 512 768
对比 MySQL 26.03% 21.37% 24.08% 11.06% 6.64% 2.21% -4.42%

结论:X86 平台下,GreatSQL 在大部分并发场景下表现比 MySQL 要更好,tpmC 最好成绩高出 26%;只在并发 768 时表现比 MySQL 略差

§ 4.2 鲲鹏 ARM 平台测试数据

  1. GreatSQL 8.4.4-4
  • innodb_buffer_pool_size=180G
  • 启用 NUMA 和网卡中断绑定,双 1 模式+开 Slow Query Log + PFS
并发数 32 64 128 256 384 512 768
Round 1 179402.52 336006.71 543341.77 341168.62 375060.08 449849.11 388444.04
Round 2 187574.45 338985.38 547766.34 342307.33 375826.13 457579.96 391517.38
Round 3 189302.81 339620.65 549039.52 342867.17 376617.37 460930.00 392838.51
Round 4 190417.68 341710.79 549561.12 344120.32 377824.86 466876.29 396247.13
Round 5 192296.94 343265.96 555050.69 470597.33 379773.78 469374.28 402251.89
Avg 187798.88 339917.90 548951.89 368212.15 377020.44 460921.93 394259.79
  1. MySQL 8.4.4
  • innodb_buffer_pool_size=180G
  • 启用 NUMA 和网卡中断绑定,双 1 模式+开 Slow Query Log + PFS.
并发数 32 64 128 256 384 512 768
Round 1 168770.24 302410.89 491520.78 323778.25 333552.38 381161.67 331701.16
Round 2 169072.51 302682.72 495234.28 324030.23 335690.91 382482.97 331718.13
Round 3 169587.21 304935.51 496005.96 328414.69 335796.34 383243.77 333856.2
Round 4 170617.79 306967.69 497659.32 328608.03 336111.10 383485.45 337922.5
Round 5 170650.99 307024.62 505156.74 335866.19 338284.19 385629.35 338669.63
Avg 169739.75 304804.29 497115.42 328139.48 335886.98 383200.64 334773.52
GreatSQL 作为基数对比(并发数) 32 64 128 256 384 512 768
对比 MySQL 10.64% 11.52% 10.43% 12.21% 12.25% 20.28% 17.77%

结论:鲲鹏 ARM 平台下,GreatSQL 在所有并发场景下表现都比 MySQL 更好,tpmC 成绩高 10% ~ 20%,相当可观

§ 4.3 海光 X86 平台测试数据

  1. GreatSQL 8.4.4-4
  • innodb_buffer_pool_size=180G
  • 启用 NUMA 和网卡中断绑定,双 1 模式+开 Slow Query Log + PFS

markdown

并发数 32 64 128 256 384 512 768
Round 1 168524.44 255680.34 290356.06 311072.19 321101.23 347455.66 360110.57
Round 2 170183.16 256274.21 291327.54 312782.24 323003.83 348087.80 361023.74
Round 3 171818.62 256281.18 291431.13 313190.33 323746.99 348500.71 362370.74
Round 4 172745.97 256427.47 292701.34 315635.62 324770.95 348694.18 362629.10
Round 5 174265.70 261658.00 293538.94 317374.76 324783.94 350864.86 363219.18
Avg 171507.58 257264.24 291871.00 314011.03 323481.39 348720.64 361870.67
  1. MySQL 8.4.4
  • innodb_buffer_pool_size=180G
  • 启用 NUMA 和网卡中断绑定,双 1 模式+开 Slow Query Log + PFS.
并发数 32 64 128 256 384 512 768
Round 1 138301.42 186540.58 213010.6 225025.92 228769.95 237837.16 270922.83
Round 2 141695.6 186810.06 218952.19 227999.09 233709.03 241560.59 271462.62
Round 3 143576.76 186837.71 220611.91 232451.64 237996.87 244398.16 274278.95
Round 4 143699.59 192074.73 224645.8 237100.89 239518.31 247889.31 276113.28
Round 5 144594.43 194054.31 229670.81 243617.29 244382.8 248431.44 284429.78
Avg 142373.56 189263.48 221378.26 233238.97 236875.39 244023.33 275441.49
GreatSQL 作为基数对比(并发数) 32 64 128 256 384 512 768
对比 MySQL 20.46% 35.93% 31.84% 34.63% 36.56% 42.90% 31.38%

结论:海光 X86 平台下,GreatSQL 在所有并发场景下表现都比 MySQL 更好,tpmC 成绩高 20% ~ 42%,相当可观

提示:在各平台环境下各并发时的 tpmC 及 Latency 曲线请查看 报告全文 (opens new window)

§ 4.4 运行 8 小时后的 tpmC 变化

§ 4.4.1 Intel X86 平台

运行 20 分钟(tpmC) 运行 8 小时(tpmC) tpmC 下降值 降为原值比率 初始表空间 8 小时后表空间 表空间增长比率 事务总数
GreatSQL(并发 256) 523153.21 474228.51 48924.70 90.65% 90G 350G 388.89% 505879211
MySQL(并发 256) 474598.40 237711.26 236887.14 50.09% 90G 222G 246.67% 253552583

tpmC 对比图

GreatSQL 8.4.4-4 vs MySQL 8.4.4 BenchmarkSQL run 8h tpmC under x86

§ 4.4.2 鲲鹏 ARM 平台

运行 20 分钟(tpmC) 运行 8 小时(tpmC) tpmC 下降值 降为原值比率 初始表空间 8 小时后表空间 表空间增长比率 事务总数
GreatSQL(并发 128) 548951.89 419824.97 129126.92 76.48% 90G 320G 255.56% 447823234
MySQL(并发 128) 497115.42 225635.72 271479.70 45.39% 90G 218G 142.22% 240701779

tpmC 对比图

GreatSQL 8.4.4-4 vs MySQL 8.4.4 BenchmarkSQL run 8h tpmC under arm

§ 4.4.3 海光 X86 平台

运行 20 分钟(tpmC) 运行 8 小时(tpmC) tpmC 下降值 降为原值比率 初始表空间 8 小时后表空间 表空间增长比率 事务总数
GreatSQL(并发 768) 361870.67 353889.88 7980.79 97.79% 90G 286G 217.78% 377483276
MySQL(并发 768) 275441.49 256531.68 18909.810 93.13% 90G 233G 158.89% 273629874

tpmC 对比图

GreatSQL 8.4.4-4 vs MySQL 8.4.4 BenchmarkSQL run 8h tpmC under Hygon

提示:在各平台环境下持续压测 8 小时后的 tpmC 及 Latency 曲线请查看 报告全文 (opens new window)

§ 5. 附录

§ 5.1 测试步骤

参考手册内容 BenchmarkSQL 性能测试,执行 TPC-C 压测,详细过程不赘述。

§ 5.2 测试工具

BenchmarkSQL 5.0。

相应代码仓库:https://gitee.com/GreatSQL/benchmarksql (opens new window)

§ 5.3 测试模式

  • 利用 BenchmarkSQL 构造测试数据,设置参数 warehouses=1000。
  • 测试数据库初始大小约 90G。
  • 服务器端开启 NUMA,并设置 innodb_numa_interleave=ON(8.4 版本下默认开启)。
  • 鲲鹏 ARM 环境中对网卡中断进行绑定操作,绑定脚本内容见下方服务端详细信息。
  • 测试过程中开启 Binlog 及双 1 模式,其余主要参数详见后面描述。

§ 5.4 BenchmarkSQL 相关参数如下

conn=jdbc:mysql://DBIP:3306/bmsql?useServerPrepStmts=false&prepStmtCacheSize=250&allowPublicKeyRetrieval=true&useSSL=false&serverTimezone=GMT&useLocalSessionState=true&maintainTimeStats=false&useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true&cacheResultSetMetadata=true&metadataCacheSize=1024&useConfigs=maxPerformance
warehouses=2000
loadWorkers=128

terminals=32
//terminals=32\64\128\256\384\512\768
runTxnsPerTerminal=0
runMins=20
limitTxnsPerMin=0

terminalWarehouseFixed=true

report-on-new-line=0
table-engine=innodb

newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

§ 5.5 数据库主要相关参数配置

[mysqld]
user=mysql
port=3306
server_id=3306
basedir=/usr/local/GreatSQL
#basedir=/usr/local/mysql
datadir=/data/GreatSQL
socket=/data/GreatSQL/mysql.sock
pid-file=mysql.pid
character-set-server=UTF8MB4
skip_name_resolve=ON
default_time_zone="+8:00"
bind_address="0.0.0.0"
secure_file_priv=/data/GreatSQL
mysql_native_password=ON

# Performance
lock_wait_timeout=3600
open_files_limit=65535
back_log=1024
max_connections=1024
max_connect_errors=1000000
table_open_cache=4096
table_definition_cache=2048
sort_buffer_size=4M
join_buffer_size=4M
read_buffer_size=8M
read_rnd_buffer_size=4M
bulk_insert_buffer_size=64M
thread_cache_size=768
interactive_timeout=600
wait_timeout=600
tmp_table_size=96M
max_heap_table_size=96M
max_allowed_packet=64M
loose-net_buffer_shrink_interval=180
sql_generate_invisible_primary_key=ON
loose-lock_ddl_polling_mode=ON
loose-lock_ddl_polling_runtime=200

# Logs
log_timestamps=SYSTEM
log_error=error.log
log_error_verbosity=3
slow_query_log=ON
log_slow_extra=ON
slow_query_log_file=slow.log
long_query_time=0.01
log_queries_not_using_indexes=ON
log_throttle_queries_not_using_indexes=60
min_examined_row_limit=100
log_slow_admin_statements=ON
log_slow_replica_statements=ON
loose-log_slow_verbosity=FULL
log_bin=binlog
binlog_format=ROW
sync_binlog=1
binlog_cache_size=4M
max_binlog_cache_size=6G
max_binlog_size=1G
loose-binlog_space_limit=500G
binlog_rows_query_log_events=ON
binlog_expire_logs_seconds=604800
binlog_checksum=CRC32
binlog_order_commits=OFF
gtid_mode=ON
enforce_gtid_consistency=ON

# Replication
relay-log=relaylog
relay_log_recovery=ON
replica_parallel_type=LOGICAL_CLOCK
replica_parallel_workers=16
replica_preserve_commit_order=ON
replica_checkpoint_period=2
loose-rpl_read_binlog_speed_limit=100

# InnoDB
innodb_buffer_pool_size=180G
innodb_buffer_pool_instances=24
innodb_data_file_path=ibdata1:12M:autoextend
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=64M
innodb_redo_log_capacity=16G
innodb_doublewrite_files=64
innodb_doublewrite_pages=64
innodb_max_undo_log_size=4G
innodb_io_capacity=40000
innodb_io_capacity_max=80000
innodb_open_files=65534
innodb_flush_method=O_DIRECT
innodb_use_fdatasync=ON
innodb_lru_scan_depth=4000
innodb_lock_wait_timeout=10
innodb_rollback_on_timeout=ON
innodb_print_all_deadlocks=ON
innodb_online_alter_log_max_size=4G
innodb_print_ddl_logs=OFF
innodb_status_file=ON
innodb_status_output=OFF
innodb_status_output_locks=ON
innodb_sort_buffer_size=64M
innodb_adaptive_hash_index=OFF
innodb_numa_interleave=ON
innodb_spin_wait_delay=6
innodb_spin_wait_pause_multiplier=50
innodb_sync_spin_loops=30
loose-innodb_print_lock_wait_timeout_info=OFF
innodb_change_buffering=none
loose-kill_idle_transaction=300
loose-innodb_data_file_async_purge=ON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

提示:在各平台环境下各并发时的 tpmC 及 Latency 曲线请查看 报告全文 (opens new window)

§ 参考资料

扫码关注微信公众号

greatsql-wx