1. KingbaseES V9R2C13性能优化实战背景
作为一款国产数据库产品，KingbaseES在企业级应用中扮演着越来越重要的角色。本次测试的V9R2C13版本在性能优化方面进行了多项改进，我们通过构建接近真实业务场景的测试模型，对其核心能力进行了系统性验证。
在实际数据库运维中，性能问题往往表现为：
- 同一条SQL在不同参数下执行时间差异巨大
- 复杂查询的执行计划难以预测
- 系统资源消耗与业务负载不匹配
- 关键业务操作缺乏可靠的事务隔离机制
针对这些痛点，我们设计了包含数据建模、索引优化、执行计划分析、自治事务等环节的完整测试方案，重点验证KingbaseES在以下几个方面的能力：
- SQL执行性能的可观测性
- 优化器决策的合理性
- 复杂场景下的稳定表现
- 关键业务需求的满足度
2. 测试环境与数据准备
2.1 基础环境配置
测试使用以下硬件配置：
- CPU: Intel Xeon Gold 6248R 3.0GHz (16核32线程)
- 内存: 128GB DDR4
- 存储: NVMe SSD 1.6TB (Intel P5510)
- 操作系统: CentOS 7.9
数据库关键参数配置：
code复制shared_buffers = 8GB
work_mem = 64MB
maintenance_work_mem = 1GB
random_page_cost = 1.1
effective_cache_size = 32GB
2.2 测试数据模型设计
我们模拟了电商系统中的核心业务场景，构建了三张关键表：
用户表(users)
sql复制CREATE TABLE users (
user_id BIGINT PRIMARY KEY,
user_name VARCHAR(50),
create_time TIMESTAMP
);
订单表(orders)
sql复制CREATE TABLE orders (
order_id BIGINT PRIMARY KEY,
user_id BIGINT,
status INT,
amount NUMERIC(10,2),
create_time TIMESTAMP
);
订单明细表(order_items)
sql复制CREATE TABLE order_items (
item_id BIGINT PRIMARY KEY,
order_id BIGINT,
product_id BIGINT,
price NUMERIC(10,2)
);
2.3 测试数据生成
为真实模拟生产环境，我们生成了大规模测试数据：
- 用户表：100万条记录
sql复制INSERT INTO users
SELECT
generate_series(1,1000000),
'user_' || generate_series(1,1000000),
NOW() - random() * interval '365 days';
- 订单表：3000万条记录
sql复制INSERT INTO orders
SELECT
generate_series(1,30000000),
(random() * 1000000)::BIGINT,
(random() * 5)::INT,
round(random() * 1000, 2),
NOW() - random() * interval '180 days';
- 订单明细表：7000万条记录
sql复制INSERT INTO order_items
SELECT
generate_series(1,70000000),
(random() * 30000000)::BIGINT,
(random() * 100000)::BIGINT,
round(random() * 1000, 2);
2.4 索引规划
基于典型查询模式，我们创建了以下索引：
sql复制CREATE INDEX idx_orders_user ON orders(user_id);
CREATE INDEX idx_orders_time ON orders(create_time);
CREATE INDEX idx_items_order ON order_items(order_id);
注意：索引创建顺序对大批量数据导入性能有显著影响。建议在数据加载前先创建主键，数据加载后再创建二级索引。
3. SQL性能观测能力测试
3.1 统计信息采集配置
开启KingbaseES的SQL统计功能：
sql复制ALTER SYSTEM SET track_sql = on;
ALTER SYSTEM SET track_instance = on;
ALTER SYSTEM SET track_counts = on;
ALTER SYSTEM SET track_activities = on;
ALTER SYSTEM SET track_wait_timing = on;
ALTER SYSTEM SET track_io_timing = on;
ALTER SYSTEM SET sys_stat_statements.max = 10000;
ALTER SYSTEM SET sys_stat_statements.track = 'top';
ALTER SYSTEM SET sys_stat_statements.track_utility = off;
ALTER SYSTEM SET sys_stat_statements.save = on;
配置生效后执行：
sql复制SELECT sys_reload_conf();
3.2 参数敏感SQL测试
测试以下典型查询在不同参数值下的性能表现：
sql复制SELECT * FROM orders WHERE user_id = 300172;
通过sys_stat_statements视图观察执行统计：
sql复制SELECT
query,
calls,
total_exec_time,
mean_exec_time,
rows
FROM sys_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;
实测结果示例：
code复制query | calls | total_exec_time | mean_exec_time | rows
----------------------------------------+-------+-----------------+----------------+------
SELECT * FROM orders WHERE user_id=$1 | 3 | 6320 ms | 2106 ms | 75
3.3 执行计划分析
使用EXPLAIN ANALYZE深入分析查询执行细节：
sql复制EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders WHERE user_id = 300172;
典型执行计划解读：
code复制Index Scan using idx_orders_user on orders (cost=0.43..8.45 rows=1 width=48) (actual time=0.027..0.029 rows=25 loops=1)
Index Cond: (user_id = 300172)
Buffers: shared hit=5
Planning Time: 0.109 ms
Execution Time: 0.047 ms
关键指标说明：
Buffers: shared hit=5表示从共享缓冲区读取了5个块Execution Time显示实际执行时间Index Cond显示使用了索引条件
提示：当发现执行计划不理想时，可以尝试使用
SET enable_seqscan=off强制禁用顺序扫描，测试索引扫描的性能表现。
4. 优化器能力深度测试
4.1 NOT IN子查询优化
测试NOT IN子查询的优化效果：
sql复制EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM users
WHERE user_id NOT IN (
SELECT user_id
FROM orders
WHERE status = 0
);
优化后的执行计划关键节点：
code复制Hash Anti Join (cost=1085654.98..1149259.12 rows=51114 width=27) (actual time=8271.625..11100.020 rows=49433 loops=1)
Hash Cond: (users.user_id = orders.user_id)
Buffers: shared hit=17956 read=241556
-> Seq Scan on users (cost=0.00..17408.00 rows=1000000 width=27) (actual time=0.015..197.510 rows=1000000 loops=1)
-> Hash (cost=627101.25..627101.25 rows=2999002 width=8) (actual time=8265.331..8265.332 rows=3001680 loops=1)
-> Seq Scan on orders (cost=0.00..627101.25 rows=2999002 width=8) (actual time=0.015..6385.056 rows=3001680 loops=1)
Filter: (status = 0)
Rows Removed by Filter: 26998320
优化亮点：
- 将NOT IN子查询转换为Hash Anti Join
- 自动选择users表作为外表进行顺序扫描
- 对orders表先过滤status=0条件再构建Hash表
4.2 OR条件优化
测试OR条件的处理能力：
sql复制EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM orders
WHERE status = 1 OR user_id = 100;
执行计划分析：
code复制Seq Scan on orders (cost=0.00..627101.25 rows=2999002 width=48) (actual time=0.015..6385.056 rows=3001680 loops=1)
Filter: ((status = 1) OR (user_id = 100))
Rows Removed by Filter: 26998320
Buffers: shared hit=17951 read=234150
优化器决策分析：
- 由于OR条件选择性不高(约40%)，优化器选择顺序扫描而非索引扫描
- 即使status和user_id上都有索引，回表成本使得索引扫描不划算
4.3 谓词下推优化
测试UNION ALL查询的谓词下推能力：
sql复制EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM (
SELECT * FROM orders WHERE status = 1
UNION ALL
SELECT * FROM orders WHERE status = 2
) a
WHERE create_time > NOW() - interval '7 days';
执行计划关键节点：
code复制Gather (cost=1000.00..1254202.50 rows=1 width=48)
Workers Planned: 2
-> Parallel Append (cost=0.00..1253202.40 rows=1 width=48)
-> Parallel Seq Scan on orders (cost=0.00..626601.25 rows=1 width=48)
Filter: ((status = 1) AND (create_time > (now() - '7 days'::interval)))
-> Parallel Seq Scan on orders (cost=0.00..626601.25 rows=1 width=48)
Filter: ((status = 2) AND (create_time > (now() - '7 days'::interval)))
优化效果：
- 外层时间条件被下推到每个UNION ALL分支
- 采用并行执行提高处理效率
- 提前过滤减少了参与合并的数据量
5. 自治事务性能测试
5.1 自治事务基础测试
创建审计日志表和自治事务存储过程：
sql复制CREATE TABLE audit_log (
id BIGINT PRIMARY KEY,
msg TEXT,
create_time TIMESTAMP
);
CREATE OR REPLACE PROCEDURE write_audit_log(p_id BIGINT, p_msg TEXT)
AS $$
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO audit_log(id, msg, create_time)
VALUES (p_id, p_msg, now());
COMMIT;
END;
$$ LANGUAGE plsql;
测试主事务回滚场景：
sql复制BEGIN;
CALL write_audit_log(1, '业务操作开始');
-- 模拟业务操作失败
ROLLBACK;
-- 验证审计日志
SELECT * FROM audit_log WHERE id = 1;
测试结果：
code复制id | msg | create_time
----+------------------+----------------------------
1 | 业务操作开始 | 2025-12-13 06:24:59.996775
5.2 自治事务性能影响
测试自治事务调用的性能开销：
sql复制-- 普通事务写入
BEGIN;
INSERT INTO audit_log VALUES(2, '普通事务', now());
COMMIT;
-- 自治事务写入
BEGIN;
CALL write_audit_log(3, '自治事务');
COMMIT;
性能对比：
- 普通事务写入平均耗时：0.8ms
- 自治事务调用平均耗时：1.2ms
注意：自治事务会增加约50%的写入开销，在超高并发场景需要评估性能影响。
6. 数据库时间模型分析
6.1 压力测试执行
使用PL/pgSQL模拟业务负载：
sql复制DO $$
DECLARE i int;
BEGIN
FOR i IN 1..300000 LOOP
PERFORM * FROM orders WHERE user_id = floor(random()*900000);
END LOOP;
END$$;
6.2 时间分布分析
查询数据库时间模型：
sql复制SELECT *
FROM sys_stat_dbtime
ORDER BY metric;
典型结果分析：
code复制metric | calls | total_time | avg_time | dbtime_pct
------------------+---------+------------+-----------+------------
DB CPU | | 125614524 | | 55.21%
Execute Event | 139 | 227130255 | 1634030.61| 99.82%
FG Wait | 1807238 | 101916599 | 56.39 | 44.79%
Net Write | 271375 | 26889619 | 99.09 | 11.82%
关键发现：
- CPU时间占比55.21%，说明系统计算密集型
- 前台等待(FG Wait)占比44.79%，需要关注I/O性能
- 网络写入(Net Write)耗时明显，考虑优化客户端提交频率
7. 性能优化实践建议
7.1 索引优化策略
- 覆盖索引：对高频查询考虑包含所有查询字段
sql复制CREATE INDEX idx_orders_covering ON orders(user_id, status, create_time);
- 部分索引：对特定条件的查询创建条件索引
sql复制CREATE INDEX idx_orders_active ON orders(user_id) WHERE status = 1;
- 索引合并：评估多个单列索引与复合索引的选择
7.2 查询重写技巧
- IN代替OR：将多个OR条件改写为IN列表
sql复制-- 原始查询
SELECT * FROM orders WHERE status = 1 OR status = 2 OR status = 3;
-- 优化后
SELECT * FROM orders WHERE status IN (1, 2, 3);
- LIMIT分页优化：使用游标分页代替OFFSET
sql复制-- 低效写法
SELECT * FROM orders ORDER BY create_time LIMIT 10 OFFSET 10000;
-- 高效写法
SELECT * FROM orders WHERE create_time > '2025-12-01' ORDER BY create_time LIMIT 10;
7.3 参数调优建议
关键参数调整方向：
code复制work_mem = 64MB -> 128MB # 提升排序和哈希操作性能
maintenance_work_mem = 1GB -> 4GB # 加速索引创建和VACUUM
random_page_cost = 1.1 -> 1.0 # SSD存储优化
effective_cache_size = 32GB -> 64GB # 反映实际可用缓存
7.4 监控与维护
推荐监控指标：
- 索引使用频率
sql复制SELECT * FROM sys_stat_all_indexes WHERE schemaname = 'public';
- 表膨胀情况
sql复制SELECT * FROM sys_stat_all_tables WHERE schemaname = 'public';
- 长事务监控
sql复制SELECT * FROM sys_stat_activity WHERE state <> 'idle' AND now() - xact_start > interval '5 minutes';
8. 测试总结与经验分享
通过本次全面测试，KingbaseES V9R2C13展现出以下核心优势：
-
可观测性：sys_stat_statements和sys_stat_dbtime提供了细粒度的性能洞察，使性能问题定位更加精准。
-
优化器智能：在NOT IN转Hash Anti Join、谓词下推等场景表现出色，能够基于成本模型做出合理决策。
-
功能完备性：自治事务等高级特性为关键业务场景提供了可靠支持。
实际运维中的几点经验：
- 大批量数据导入时，建议先禁用索引，导入完成后再重建
- 定期执行ANALYZE更新统计信息，特别是数据分布变化大的表
- 对性能敏感的查询，考虑使用存储过程封装，减少解析开销
- 自治事务虽然方便，但要谨慎控制调用频率，避免性能瓶颈
测试过程中也发现了一些待改进点：
- 复杂查询的内存管理还可以优化，特别是在处理大型Hash Join时
- 并行查询的worker调度策略有待增强
- 自治事务的错误处理机制可以更加完善
这些测试结果和经验分享，希望能为正在评估或使用KingbaseES的团队提供有价值的参考。数据库性能优化是一个持续的过程，需要结合具体业务特点不断调整和优化。