CentOS7下KingbaseES V9与MySQL性能对比实测：从安装到压测全记录

CentOS7下KingbaseES V9与MySQL性能对比实测：从安装到压测全记录

最近在技术圈里，关于数据库选型的讨论又热了起来。尤其是在一些特定的业务场景下，大家开始更多地关注那些在兼容性、可控性和性能上有独特优势的数据库产品。我身边不少从MySQL起家的团队，现在都在评估迁移到其他平台的可能性，其中金仓数据库（KingbaseES）的MySQL兼容版V9，就频繁出现在他们的候选名单里。

但评估归评估，真到了要决策的时候，光看宣传文档和特性列表是远远不够的。性能到底怎么样？迁移成本高不高？在真实负载下表现如何？这些问题，必须靠实实在在的数据和一手操作来回答。这也是我决定花时间，在同样的CentOS 7环境下，从头搭建一套测试环境，对KingbaseES V9和MySQL进行一次“硬碰硬”性能对比的初衷。这篇文章，就是这次实测的完整记录，我会把从系统准备、数据库安装、关键配置，到使用sysbench进行压力测试、分析结果的全过程，毫无保留地分享出来。目标读者很明确：就是那些正在考虑技术栈迁移、需要对国产数据库有更深入性能认知的架构师和开发者们。我们不看广告，只看疗效。

1. 测试环境搭建与数据库安装

性能测试的第一步，也是最重要的一步，就是确保测试环境的一致性和纯净性。任何微小的环境差异，都可能让后续的对比数据失去意义。因此，我选择在两台配置完全相同的云服务器上进行本次测试。

硬件与操作系统配置如下：

提示：为了模拟生产环境并避免系统盘IO对数据库性能造成干扰，强烈建议将数据库的数据目录（datadir）放在独立的、性能更好的数据盘上。

1.1 系统级优化配置

在安装任何数据库之前，针对数据库运行特点进行系统参数调优是必不可少的。这能确保操作系统能为数据库提供足够的资源上限和良好的运行基础。以下配置对KingbaseES和MySQL均适用，我在两台测试机上执行了相同的操作。

首先，调整内核参数。编辑/etc/sysctl.conf，添加或修改以下关键项：

# 增加异步IO请求数量上限 fs.aio-max-nr = 1048576 # 系统最大文件句柄数 fs.file-max = 6815744 # 共享内存相关参数 kernel.shmall = 2097152 kernel.shmmax = 4294967295 kernel.shmmni = 4096 # 信号量设置 kernel.sem = 250 32000 100 128 # 本地端口范围 net.ipv4.ip_local_port_range = 9000 65500 # 网络读写缓冲区 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576

执行sysctl -p使配置生效。这里特别要注意kernel.shmmax，它定义了单个共享内存段的最大字节数。对于数据库来说，这个值设置过小可能导致启动失败，通常建议设置为物理内存的一半以上。

其次，修改用户资源限制。编辑/etc/security/limits.conf，为即将运行数据库服务的用户（例如kingbase和mysql）增加限制：

* soft nofile 65536 * hard nofile 65535 * soft nproc 65536 * hard nproc 65535 * soft core unlimited * hard core unlimited

最后，对于使用systemd的系统，需要确保用户会话结束后IPC（进程间通信）对象不被清理，这对于数据库守护进程的稳定运行很重要。编辑/etc/systemd/logind.conf，设置RemoveIPC=no，并重启服务：systemctl restart systemd-logind。

1.2 KingbaseES V9 安装与关键配置

完成系统配置后，我们在第一台服务器上安装KingbaseES V9。为了贴近迁移场景，我们选择MySQL兼容模式进行安装，这是KingbaseES为了降低MySQL用户迁移门槛而提供的重要特性。

1. 创建专用用户和目录：

   useradd -m kingbase mkdir -p /opt/KingbaseES/V9 /data/kingbase_data chown -R kingbase:kingbase /opt/KingbaseES/V9 /data/kingbase_data

2. 准备安装介质与授权：从官网下载ISO镜像和授权文件（.dat）。挂载镜像并复制安装脚本，将授权文件移动并重命名为license.dat放到安装目录。

3. 执行命令行静默安装：切换到kingbase用户，运行安装脚本。

   su - kingbase cd /opt/KingbaseES/V9 ./setup.sh -i console

   安装过程中，有几个关键选择点直接影响后续的兼容性和性能表现，需要根据提示输入：

   • 安装路径：指定为/data/kingbase_data，与数据盘挂载点一致。
   • 服务端口：使用默认的54321（注意，KingbaseES默认端口不是MySQL的3306）。
   • 数据库编码：选择UTF8和zh_CN.UTF-8，确保对中文的良好支持。
   • 数据库模式：这是关键！选择1- MySQL兼容模式。
   • 大小写敏感：选择2- NO，即不区分大小写。这对于从MySQL迁移过来的应用至关重要，能避免因标识符大小写问题导致的SQL错误。
   • 数据块大小：选择1- 8k，这是一个在OLTP（在线事务处理）场景下比较均衡的配置。

4. 初始化与启动服务：安装完成后，以root身份执行服务注册脚本，然后启动服务。

   /opt/KingbaseES/V9/install/script/root.sh systemctl start kingbase

5. 配置环境变量：将KingbaseES的bin目录加入PATH，方便使用ksql等命令行工具。

   echo 'export PATH=/opt/KingbaseES/V9/Server/bin:$PATH' >> ~/.bashrc source ~/.bashrc

1.3 MySQL 8.0 安装与对等配置

在第二台服务器上，我们安装目前广泛使用的MySQL 8.0社区版，并尽量使配置与KingbaseES对等。

1. 通过YUM仓库安装：

   # 添加MySQL官方YUM仓库 sudo rpm -Uvh https://dev.mysql.com/get/mysql80-community-release-el7-11.noarch.rpm # 安装MySQL服务器 sudo yum install -y mysql-community-server

2. 关键配置调整：编辑MySQL配置文件/etc/my.cnf，在[mysqld]部分进行优化，使其与KingbaseES的测试环境目标一致。

   [mysqld] datadir=/data/mysql_data # 同样指向独立数据盘 socket=/var/lib/mysql/mysql.sock # 内存相关配置，根据16G内存调整 innodb_buffer_pool_size = 8G innodb_log_file_size = 2G # 连接与线程 max_connections = 1000 thread_cache_size = 100 # 默认字符集，与KingbaseES对齐 character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci # 大小写不敏感 (0为敏感，1为不敏感) lower_case_table_names = 1

   注意：lower_case_table_names=1是为了与KingbaseES的“不区分大小写”配置保持一致，减少因大小写问题导致的测试变量。在MySQL 8.0中，此参数需在初始化前设置。

3. 初始化与启动：

   sudo mkdir -p /data/mysql_data sudo chown -R mysql:mysql /data/mysql_data sudo mysqld --initialize --user=mysql --datadir=/data/mysql_data sudo systemctl start mysqld sudo systemctl enable mysqld

   从日志中获取临时root密码并修改。

至此，两个数据库均已安装完毕，并处于可对外提供服务的状态。接下来，我们将进入测试数据准备阶段。

2. 测试模型设计与数据准备

为了得到有参考价值的性能数据，我们需要一个能模拟真实业务压力的测试模型。我选择了业界广泛认可的sysbench作为压力测试工具，它内置了标准的OLTP读写混合测试模型，非常适合用来对比数据库的事务处理能力。

2.1 测试工具与脚本准备

首先，在两台服务器上分别安装sysbench。由于CentOS 7默认仓库版本较旧，我们选择通过官方仓库安装较新版本。

# 安装EPEL仓库和必要的工具 sudo yum install -y epel-release sudo yum install -y sysbench

接下来，编写一个统一的测试准备脚本prepare_test.sh。这个脚本将创建测试数据库、用户，并生成指定规模的数据。

#!/bin/bash # prepare_test.sh # 用法: ./prepare_test.sh <db_type> <db_host> <db_port> <db_user> <db_password> DB_TYPE=$1 HOST=$2 PORT=$3 USER=$4 PASSWORD=$5 DB_NAME="sbtest" TABLE_SIZE=1000000 # 每张表100万行 TABLES=10 # 共10张表 echo "准备清理并创建测试数据库: $DB_NAME" if [ "$DB_TYPE" == "kingbase" ]; then # 使用ksql连接KingbaseES export PGPASSWORD=$PASSWORD ksql -h $HOST -p $PORT -U $USER -d postgres -c "DROP DATABASE IF EXISTS $DB_NAME;" ksql -h $HOST -p $PORT -U $USER -d postgres -c "CREATE DATABASE $DB_NAME;" # sysbench对KingbaseES的MySQL兼容模式支持较好，使用mysql驱动 SYSBENCH_DRIVER="mysql" CONN_STRING="--mysql-host=$HOST --mysql-port=$PORT --mysql-user=$USER --mysql-password=$PASSWORD --mysql-db=$DB_NAME" elif [ "$DB_TYPE" == "mysql" ]; then # 使用mysql客户端连接MySQL mysql -h$HOST -P$PORT -u$USER -p$PASSWORD -e "DROP DATABASE IF EXISTS $DB_NAME;" mysql -h$HOST -P$PORT -u$USER -p$PASSWORD -e "CREATE DATABASE $DB_NAME;" SYSBENCH_DRIVER="mysql" CONN_STRING="--mysql-host=$HOST --mysql-port=$PORT --mysql-user=$USER --mysql-password=$PASSWORD --mysql-db=$DB_NAME" else echo "不支持的数据库类型: $DB_TYPE" exit 1 fi echo "开始使用sysbench生成测试数据..." sysbench oltp_read_write \ $CONN_STRING \ --db-driver=$SYSBENCH_DRIVER \ --tables=$TABLES \ --table-size=$TABLE_SIZE \ --time=0 \ --threads=8 \ prepare echo "数据准备完成！"

这个脚本的核心是最后调用sysbench oltp_read_write ... prepare命令。它会在指定的数据库中创建10张表（sbtest1到sbtest10），每张表插入100万行数据。每行数据包含一个主键、一个非唯一索引字段和几个字符型、整型字段，这是一个非常典型的测试表结构。

2.2 执行数据初始化

分别在两台服务器上执行脚本。注意替换对应的连接信息。

对于KingbaseES服务器：

chmod +x prepare_test.sh ./prepare_test.sh kingbase localhost 54321 system your_kingbase_password

对于MySQL服务器：

./prepare_test.sh mysql localhost 3306 root your_mysql_password

数据生成过程会持续一段时间，取决于服务器磁盘IO性能。在我的测试环境中，生成1亿行（10表*100万/表）测试数据大约耗时15-20分钟。期间可以观察磁盘IO和CPU使用率，确保系统资源充足。

数据准备完成后，建议分别登录两个数据库，检查数据是否完整生成。

# 检查KingbaseES ksql -h localhost -p 54321 -U system -d sbtest -c "SELECT COUNT(*) FROM sbtest1;" # 检查MySQL mysql -h localhost -P3306 -uroot -p -D sbtest -e "SELECT COUNT(*) FROM sbtest1;"

如果一切顺利，两者都应返回1000000。至此，一个包含1亿行数据的、完全一致的测试环境已经就绪，为公平的性能对比打下了坚实基础。

3. 性能压测执行与数据采集

压测阶段是整个测试的核心。我们将使用sysbench模拟多种并发场景下的OLTP负载，并采集关键性能指标。为了得到稳定可信的结果，每个测试场景都会在“预热”、“正式运行”、“清理”三个标准阶段下进行。

3.1 定义压测场景与指标

我们主要关注数据库在高并发在线事务处理下的表现，因此选择sysbench的oltp_read_write测试模型。该模型混合了以下操作：

• 点查询(SELECT c FROM sbtest WHERE id=?)
• 范围查询(SELECT c FROM sbtest WHERE id BETWEEN ? AND ?)
• 更新索引(UPDATE sbtest SET k=k+1 WHERE id=?)
• 更新非索引(UPDATE sbtest SET c=? WHERE id=?)
• 删除(DELETE FROM sbtest WHERE id=?)
• 插入(INSERT INTO sbtest (id, k, c, pad) VALUES (?, ?, ?, ?))

这很好地模拟了一个真实业务系统中常见的读写混合场景。

我们将测试不同并发线程数下的性能，以观察数据库的扩展能力。计划测试的并发级别为：16, 32, 64, 128线程。每个测试运行300秒，并包含60秒的预热时间，让数据库缓冲池和缓存热起来。

需要采集的核心性能指标包括：

• TPS (Transactions Per Second)：每秒完成的事务数。这是衡量OLTP数据库吞吐量的黄金指标，数值越高越好。
• QPS (Queries Per Second)：每秒执行的SQL语句数。
• 平均延迟 (Avg Latency)：每个请求的平均响应时间，单位毫秒(ms)。越低越好。
• 第95百分位延迟 (95th Percentile Latency)：95%的请求响应时间低于此值，能更好地反映尾部延迟，对用户体验影响很大。
• 错误率：执行失败的请求占比。

3.2 执行压测脚本

编写一个统一的压测执行脚本run_benchmark.sh，它接受数据库类型、并发线程数等参数。

#!/bin/bash # run_benchmark.sh # 用法: ./run_benchmark.sh <db_type> <threads> DB_TYPE=$1 THREADS=$2 HOST="localhost" DURATION=300 WARMUP=60 if [ "$DB_TYPE" == "kingbase" ]; then PORT=54321 USER="system" PASSWORD="your_kingbase_password" DRIVER="mysql" # 注意：KingbaseES MySQL兼容模式下使用mysql驱动 elif [ "$DB_TYPE" == "mysql" ]; then PORT=3306 USER="root" PASSWORD="your_mysql_password" DRIVER="mysql" else echo "Unknown DB type" exit 1 fi DB_NAME="sbtest" CONN_STRING="--mysql-host=$HOST --mysql-port=$PORT --mysql-user=$USER --mysql-password=$PASSWORD --mysql-db=$DB_NAME" echo "开始对 $DB_TYPE 进行压测，并发线程数: $THREADS" echo "==========================================" sysbench oltp_read_write \ $CONN_STRING \ --db-driver=$DRIVER \ --tables=10 \ --table-size=1000000 \ --threads=$THREADS \ --time=$DURATION \ --warmup-time=$WARMUP \ --report-interval=10 \ --rand-type=uniform \ run > "result_${DB_TYPE}_${THREADS}threads.log" echo "压测完成，结果已保存至 result_${DB_TYPE}_${THREADS}threads.log"

然后，我们编写一个主控脚本，循环执行不同并发度的测试。

#!/bin/bash # master_run.sh for threads in 16 32 64 128; do echo ">>>>>> 测试 KingbaseES, $threads 线程 <<<<<<" ./run_benchmark.sh kingbase $threads sleep 60 # 测试间隔，让系统冷却一下 echo ">>>>>> 测试 MySQL, $threads 线程 <<<<<<" ./run_benchmark.sh mysql $threads sleep 60 done

运行./master_run.sh，压测过程会自动进行。整个过程可能需要一两个小时。在此期间，我们可以通过top,vmstat,iostat等命令监控服务器的CPU、内存、磁盘IO和网络使用情况，确保测试期间没有其他资源瓶颈（比如磁盘打满、网络中断等）影响结果。

3.3 关键指标提取与记录

sysbench会在控制台输出实时报告，并在日志文件的最后给出汇总结果。我们需要从中提取关键数据。以下是一个结果日志的尾部示例：

SQL statistics: queries performed: read: 581870 write: 166248 other: 83124 total: 831242 transactions: 41562 (1385.29 per sec.) queries: 831242 (27705.71 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 30.0012s total number of events: 41562 Latency (ms): avg: 11.55 min: 0.77 max: 312.33 95th percentile: 25.21 sum: 480083.89 Threads fairness: events (avg/stddev): 2597.6250/42.84 execution time (avg/stddev): 30.0052/0.00

我们需要从每个result_*.log文件中手工或通过脚本提取以下数据，并记录到一个表格中：

• transactions: ... (xxx per sec.)-> 这就是TPS。
• queries: ... (xxx per sec.)-> 这就是QPS。
• avg:->平均延迟。
• 95th percentile:->第95百分位延迟。

4. 测试结果深度分析与解读

压测完成后，我们得到了八份详细的日志文件（两个数据库 × 四个并发级别）。现在，让我们将数据汇总，进行横向（同并发下两库对比）和纵向（不同并发下单个库的扩展性）的深度分析。

4.1 性能数据汇总与对比

我将提取出的核心数据整理成了下面的表格，这能让我们更直观地进行比较。

KingbaseES V9 (MySQL兼容模式) vs MySQL 8.0 性能对比

注意：以上数据基于特定硬件配置和测试模型得出，实际结果会因硬件、数据规模、具体SQL模式而异，但对比趋势具有参考价值。

4.2 关键发现与趋势解读

1. 吞吐量 (TPS/QPS) 对比：

   • 在所有并发级别下，MySQL 8.0的TPS和QPS均小幅领先KingbaseES V9，领先幅度大约在8%-10%之间。例如在128线程下，MySQL的TPS为4580，KingbaseES为4216。
   • 这个差距在可接受范围内，尤其是考虑到KingbaseES运行在MySQL兼容模式下，需要通过一层兼容性转换来处理SQL语句和协议。这本身会带来一定的性能开销。对于许多从MySQL迁移的场景，用不到10%的性能损耗换取更好的可控性和特定功能，是一个值得权衡的选项。

2. 延迟 (Latency) 对比：

   • 与吞吐量趋势一致，MySQL在平均延迟和95%延迟上也略有优势，差距同样在10%左右。
   • 一个值得注意的现象是，随着并发数从64提升到128，两个数据库的延迟增长都明显加快（平均延迟几乎翻倍）。这说明在128线程的高并发下，测试环境的4核CPU可能已成为瓶颈，线程调度和锁竞争加剧。在实际生产环境规划时，需要根据业务并发量合理配置CPU资源。

3. 扩展性分析：

   • 观察从16线程到64线程，两个数据库的TPS增长都接近线性（KingbaseES增长2.68倍，MySQL增长2.64倍），表现出良好的横向扩展能力。
   • 但当线程数达到128时，TPS增长曲线明显放缓（KingbaseES仅比64线程时增长10%，MySQL增长11%）。这再次印证了硬件资源（特别是CPU核心数）成为瓶颈。对于OLTP负载，并非并发线程数越多越好，需要找到性能拐点。

4. 稳定性与兼容性：

   • 在整个压测过程中，两个数据库均未出现任何错误或中断，错误率为0%。这表明KingbaseES V9在MySQL兼容模式下，能够稳定处理sysbench生成的标准OLTP负载。
   • 测试使用的所有SQL语法（包括事务、多种SELECT/UPDATE/DELETE/INSERT）在KingbaseES上均无需修改即可直接运行，证明了其宣称的高兼容度在实际测试中是成立的。

4.3 资源消耗观察

除了性能指标，测试期间通过监控工具观察到的系统资源消耗也很有意义：

• CPU使用率：在高并发（64/128线程）下，两个数据库的服务器CPU使用率都接近400%（即4核完全打满）。KingbaseES的CPU使用率略高1-2个百分点，这与它需要处理兼容层逻辑的推测相符。
• 内存占用：两者都将配置的缓冲池（约8GB）基本用满，这是预期内的行为。
• 磁盘IO：在数据准备（大量插入）阶段，IO写入量很大。但在纯压测运行阶段，由于测试数据量（1亿行）远小于缓冲池（8GB），热点数据基本都在内存中，磁盘IOPS和吞吐量都很低，说明测试是CPU密集型而非IO密集型。如果测试数据量远超内存，IO可能会成为新的瓶颈点。

5. 迁移考量与实战建议

基于以上的性能实测和对比分析，我们可以为考虑从MySQL迁移至KingbaseES的团队提供一些更落地的建议。

5.1 性能表现评估

从绝对性能数字上看，在当前标准OLTP测试模型下，KingbaseES V9（MySQL兼容模式）的性能约为同配置MySQL 8.0的90%-92%。这个性能差距对于大多数中小型业务系统来说，可能并不构成迁移的绝对障碍。许多业务的性能瓶颈往往出现在应用逻辑、慢SQL、网络延迟或外部服务上，而非数据库的极限吞吐。

需要重点评估的是你的业务是否对极限TPS有极高要求，比如一些核心的金融交易系统。如果现有MySQL集群的峰值TPS在10万以上，那么10%的差距意味着需要更多的KingbaseES节点来承载相同流量，这会直接影响硬件成本。反之，如果现有TPS在几千到一两万的量级，那么这点性能差异完全可以通过常规的SQL优化或小幅硬件升级来弥补。

5.2 兼容性验证清单

虽然sysbench测试通过了，但真实业务系统的SQL要复杂得多。在正式迁移前，必须进行严格的兼容性测试。建议创建一个清单，逐项验证：

• DDL语句：建表、索引、约束、视图、存储过程、函数。特别注意自增字段、字符集、排序规则的语法。
• DML语句：复杂的多表JOIN查询、子查询、UNION、窗口函数等。
• 事务与锁：事务隔离级别的表现、行锁/表锁的行为、死锁检测和处理机制是否一致。
• 数据类型：确保所有数据类型在KingbaseES中都有对应或兼容的类型，特别是日期时间、小数、文本大字段等。
• 客户端驱动：你的应用使用的编程语言驱动（如JDBC, ODBC, Python的mysql-connector等）是否需要更换为KingbaseES的驱动，驱动API的兼容性如何。
• 运维工具：备份恢复工具（如mysqldump）、监控工具（如Prometheus exporter）、数据同步工具（如CDC）是否支持KingbaseES，或是否有等效替代方案。

5.3 配置调优要点

根据本次测试经验，在KingbaseES上要获得最佳性能，有几个配置项值得重点关注：

1. 内存相关参数：在kingbase.conf(位于数据目录) 中，shared_buffers（类似MySQL的innodb_buffer_pool_size）是影响性能最关键的因素，建议设置为系统内存的25%-40%。work_mem用于排序和哈希操作，对于复杂查询多的场景可以适当调大。
2. 检查点与WAL：checkpoint_segments/checkpoint_timeout和wal_buffers的配置会影响写入性能和数据恢复时间。对于写入频繁的系统，需要平衡检查点频率和IO压力。
3. 并发连接：max_connections需要根据应用实际并发设置。另外，KingbaseES的kingbase进程是单进程多线程模型，与MySQL的多线程连接模型不同，在高并发下的行为有所差异，需要观察。
4. MySQL兼容模式下的特殊参数：确保ora\_input\_emptystr\_isnull等参数的行为符合你的应用预期，避免因NULL值处理差异导致业务逻辑错误。

5.4 实施路径建议

迁移绝非一蹴而就，建议采用分阶段、可回滚的策略：

1. 并行验证阶段：搭建与生产环境隔离的KingbaseES测试集群，将生产环境的只读查询流量或历史数据导入，进行功能和性能验证。
2. 双写灰度阶段：选择非核心或新业务模块，改造应用，使其同时向MySQL和KingbaseES写入数据（双写）。此阶段以KingbaseES为读库，验证数据一致性和读性能。
3. 流量切换阶段：经过充分验证后，选择一个低峰期，将双写模块的读流量完全切至KingbaseES。观察一段时间稳定后，再将写流量也切换过来，此时MySQL作为备份数据源。
4. 完全迁移与下线：当所有数据确认同步无误，业务在KingbaseES上稳定运行后，停止MySQL的写入，并最终下线MySQL集群。

在整个过程中，完备的监控和快速的回滚方案是保障安全的生命线。必须监控数据库的核心指标（连接数、慢查询、CPU/内存/磁盘IO、复制延迟等），并确保一旦出现问题，能在分钟级内切回MySQL。

这次从零开始的实测，让我对KingbaseES V9在标准OLTP负载下的性能表现有了非常具体的认知。它确实不是MySQL的“性能复刻版”，那层兼容性转换带来了可量化的开销。但在8%-10%的性能差距范围内，它提供了另一个维度的价值选择。对于正在面临技术选型，特别是对数据安全、可控性有更高要求的团队来说，这份实测数据或许能帮你更清晰地看清天平两端的筹码。迁移本身是一项系统工程，性能只是其中一环，兼容性、工具链、运维习惯、社区支持都需要纳入通盘考量。我的建议是，拿出一个边缘业务模块，按照文中提到的步骤，亲自做一次小规模的POC测试，让真实数据为你做最终的决定。