金仓数据库 V9R3C18 MySQL 兼容版体验(性能篇)

原创严少安 2天前

6月18日，金仓社区正式开启了新一期产品体验官活动，主题是MySQL兼容深度体验，具体要求我列在文末。

书接上文，前面我们介绍过了新增语法篇，本文将带大家一起看看查询与写入优化的相关内容。

01. 新版本速览：KES V9R3C18 MySQL兼容版

6月9日，KingbaseES MySQL兼容版 V9R3C18 发布。该版本重点强化了MySQL兼容性，全面优化数据库性能、高可用能力、云原生适配、数据安全与运维工具体系。

核心亮点速览：

维度	关键能力
兼容性	MySQL 语法/函数/协议/驱动全栈兼容
性能	OR Expansion、DISTINCT+LIMIT 下推、Memoize 缓存、扩展统计信息
高可用	集群扩容速率控制、并行故障检测、智能故障恢复、重做日志 DDL 解析
安全	渔翁/格尔加密设备透明加密
运维	kbinspect 健康检查、sys_guc 参数管理、uninstall.sh 集群卸载、HA-Log 分析
多模	时序数据库 KES TimeSeries 扩展插件
部署	安装包体积缩减约 50%、容器环境授权

在性能方面，新增OR Expansion技术，并通过优化QueryMapping和Hint机制，显著提升复杂查询效率；DISTINCT支持并行及LIMIT下推以规避全表扫描；支持参数化结果集缓存，通过精细化内存调度及代价惩罚引导，结合完善的多列统计信息优化基数估计，大幅提升执行效率。

性能部分具体更新如下：

QueryMapping能力增强

支持更全面的SQL语法（DQL、DML及特定DDL），引入语句级Wildcard模式，支持从表、列到变长数组的模糊匹配；增强负数常量精准识别能力，并配套提供了SQL转换工具、DEBUG工具及数据缓存机制，显著降低高并发复杂业务场景下的解析开销，提升系统响应速度。

Hint执行控制增强

支持通过Hint优化查询执行性能，包括：指定UNION节点并行执行、为UNION及DISTINCT类型指定HashAgg聚合算法、使用Rows Hint修正聚合节点基数估计，同时，支持通过Hint设置缓存参数，以及在调用存储过程中修改全局变量。

查询规则优化

支持 OR EXPANSION，可将WHERE或ON条件内出现的OR或AND OR条件语句转化为UNION ALL形式，优化执行计划，提升查询效率。
针对包含等价性谓词和传递谓词条件的复杂查询场景进行性能优化，在处理百万行数据时实现约30%性能提升。
支持子查询等价谓词传递，可将SQL语句中子查询通过等价下推或上推方式提升查询性能。
支持将父查询的连接谓词下推至子查询中执行，提前过滤子查询数据，减少中间结果集规模，降低连接操作的计算开销。
对目标列中包含相关标量子查询的复杂查询场景进行逻辑优化，在100并发场景下TPS提升约60%，响应时间缩短约90%。
优化非关联 IN/SOME/ANY/ALL 子查询处理，支持将该类子查询放到Array数组中，对于仅涉及外表的查询，可将过滤条件一并发送至远端KingbaseES，减少远程数据获取量；对于仅涉及本地表的查询，利用生成的initplan使外部查询块可利用索引扫描，减少扫描次数。

DISTINCT处理能力增强

支持DISTINCT并行查询，在数据库开启并行查询且表具有足够并行度时，可提升大型DISTINCT去重查询的执行效率。
优化DISTINCT语句，在特定场景下，支持使用LIMIT 1代替DISTINCT，或在DISTINCT并行查询效果不佳时利用GROUP BY代替DISTINCT实现并行。
针对 DISTINCT+LIMIT 场景，支持将LIMIT值下推至HashAgg节点，在哈希表构建过程中监控唯一值数量，达到阈值后停止从下层扫描节点拉取输入数据，避免全表扫描，降低I/O与CPU开销。

执行计划效率提升

当函数属性为IMMUTABLE、STABLE、RESULT_CACHE时，支持结果集缓存能力，极大提升函数的执行效率。
新增对SYSCACHE系统缓存、RELCACHE元数据缓存及PBE执行计划缓存容量的独立管控能力，支持各类缓存达到阈值时自动执行置换与释放，实现内存资源的精细化调度，提升高并发场景下的系统稳定性。
支持根据NestloopJoin/MergeJoin慢SQL特征，判断是否施加代价惩罚，引导优化器避开性能较差的执行计划。
支持参数化结果集缓存，在执行NestLoop及SubPlan查询时，可通过Memoize节点缓存输入参数对应的查询结果，当相同参数再次出现时直接返回缓存数据，以跳过重复扫描来提升查询性能。

扩展统计信息完善

支持基于函数依赖与多列MCV统计信息，优化含IN/ANY/ALL条件的查询执行计划，有效提升查询技术估计准确性与优化器决策能力。

分区表查询优化

优化多级分区表查询计划生成速度。在分区数量多、高并发场景下，提升查询性能。

02. KingbaseES V9R3C18 实践体验

先来准备数据库环境，这里已经安装好了最新版本。

[shawnyan@kes ~]$ ksql -U system
License Type: 企业版.
Type "help" for help.

(system@kes.shawnyan.cn) [kingbase] 13:07:56# select version();
         version
-------------------------
 KingbaseES V009R003C018
(1 row)

(system@kes.shawnyan.cn) [kingbase] 13:07:19# show database_mode;
 database_mode
---------------
 mysql
(1 row)

接下来根据更新的内容依次看看实践结果。

2.1 OR Expansion

概念介绍：

OR Expansion（OR 扩展）是 KingbaseES V9R3C18 新增的基于代价的逻辑优化规则。当 WHERE 或 ON 条件中出现复杂的 OR 条件时，优化器可将 OR 条件拆分为多个 UNION ALL 子查询。拆分后的每个子查询可以利用索引、分区剪枝等优化手段，显著提升查询性能。

核心参数：

kdb_rbo.rbo_rule：启用/禁用基于代价的逻辑优化规则（默认 off）
kdb_rbo.or_expansion_layer：拆分 OR 条件的层数（默认 3）

实践步骤：

准备测试数据

DROP TABLE IF EXISTS t1, t2;
CREATE TABLE t1 (a int, b int);
CREATE TABLE t2 (a int, b int);

INSERT INTO t1 SELECT generate_series(1,10000), generate_series(1,10000);
INSERT INTO t2 SELECT generate_series(1,10000), generate_series(1,10000);
CREATE INDEX idx1_a ON t1(a);
ANALYZE;

– 场景：关闭 OR Expansion（性能差）

SET kdb_rbo.rbo_rule = off;

EXPLAIN ANALYZE SELECT * FROM t1, t2 WHERE t1.a = 1 OR t1.b = t2.b;
-- 执行计划： Nested Loop + Join Filter (OR 条件)
-- 执行时间： ~10s
-- 原因： OR 条件导致无法使用 t1.a 上的索引

kingbase=# EXPLAIN ANALYZE SELECT * FROM t1, t2 WHERE t1.a = 1 OR t1.b = t2.b;
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.00..1750315.00 rows=19999 width=16) (actual time=0.023..9945.430 rows=19999 loops=1)
   Join Filter: ((t1.a = 1) OR (t1.b = t2.b))
   Rows Removed by Join Filter: 99980001
   ->  Seq Scan on t1  (cost=0.00..145.00 rows=10000 width=8) (actual time=0.011..3.903 rows=10000 loops=1)
   ->  Materialize  (cost=0.00..195.00 rows=10000 width=8) (actual time=0.000..0.371 rows=10000 loops=10000)
         ->  Seq Scan on t2  (cost=0.00..145.00 rows=10000 width=8) (actual time=0.004..0.722 rows=10000 loops=1)
 Planning Time: 0.216 ms
 Execution Time: 9947.361 ms
(8 rows)

场景：开启 OR Expansion（性能大幅提升）

SET kdb_rbo.rbo_rule = on;
SET kdb_rbo.or_expansion_layer = 1;

EXPLAIN ANALYZE SELECT * FROM t1, t2 WHERE t1.a = 1 OR t1.b = t2.b;
-- 执行计划：
--   Append
--     -> Nested Loop  (索引扫描 t1.a=1)
--     -> Hash Join    (t1.b = t2.b 谓词下推)
-- 执行时间：~7 ms

kingbase=# EXPLAIN ANALYZE SELECT * FROM t1, t2 WHERE t1.a = 1 OR t1.b = t2.b;
                                                        QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
 Append  (cost=0.29..905.79 rows=13333 width=16) (actual time=0.121..6.130 rows=19999 loops=1)
   ->  Nested Loop  (cost=0.29..253.30 rows=10000 width=16) (actual time=0.121..1.642 rows=10000 loops=1)
         ->  Index Scan using idx1_a on t1  (cost=0.29..8.30 rows=1 width=8) (actual time=0.108..0.110 rows=1 loops=1)
               Index Cond: (a = 1)
         ->  Seq Scan on t2  (cost=0.00..145.00 rows=10000 width=8) (actual time=0.008..0.616 rows=10000 loops=1)
   ->  Hash Join  (cost=236.66..452.49 rows=3333 width=16) (actual time=1.303..3.340 rows=9999 loops=1)
         Hash Cond: (t2_1.b = t1_1.b)
         ->  Seq Scan on t2 t2_1  (cost=0.00..145.00 rows=10000 width=8) (actual time=0.006..0.514 rows=10000 loops=1)
         ->  Hash  (cost=195.00..195.00 rows=3333 width=8) (actual time=1.289..1.289 rows=9999 loops=1)
               Buckets: 16384 (originally 4096)  Batches: 1 (originally 1)  Memory Usage: 519kB
               ->  Seq Scan on t1 t1_1  (cost=0.00..195.00 rows=3333 width=8) (actual time=0.005..0.639 rows=9999 loops=1)
                     Filter: kes_lnnvl((a = 1))
                     Rows Removed by Filter: 1
 Planning Time: 0.316 ms
 Execution Time: 6.759 ms
(15 rows)

性能提升一个数量级。

2.2 QueryMapping 增强

概念介绍：

QueryMapping 是 KingbaseES 的 SQL 语句转换/映射机制，用于在不修改应用代码的前提下对特定 SQL 进行优化改写。显著降低高并发复杂业务场景下的解析开销，提升系统响应速度。当单个 SQL 语句有性能问题但无法修改应用代码时，QueryMapping 可以在数据库层面对该 SQL 进行无损改写。

V9R3C18 对 QueryMapping 做了全面增强：

支持更全面的 SQL 语法（DQL、DML 及特定 DDL）
引入语句级 Wildcard 模式，支持从表、列到变长数组的模糊匹配
增强负数常量精准识别能力
配套提供 SQL 转换工具、DEBUG 工具及数据缓存机制

示例：

SET sys_query_mapping.enable = on;
SET query_mapping_spi.enable = all_on;

-- 将SQL SELECT $1,$2 替换为 SELECT $2,$1
SELECT create_query_rule(
'qm0', -- 规则名
'SELECT $1,$2', -- 匹配的sql
'SELECT $2,$1', -- 需要替换的sql
true, -- 该规则是否生效
'semantics' -- 级别
);

explain (usingquerymapping) select 1,2;
kingbase=# select 1,2;
 ?column? | ?column?
----------+----------
 2        | 1
(1 row)

2.3 Hint 执行控制增强

概念介绍：

Hint（提示）是 KingbaseES 提供的优化器控制机制，允许用户手动指定执行计划策略。V9R3C18 增强了 Hint 能力，新增以下功能：

UNION 并行执行：指定 UNION 节点以并行模式执行
HashAgg 聚合算法：为 UNION 和 DISTINCT 类型指定使用 HashAgg 算法
Rows Hint：修正聚合节点的基数估计
缓存参数设置：通过 Hint 设置结果集缓存参数
存储过程全局变量修改：在调用存储过程中通过 Hint 修改全局变量

示例：

基础数据

CREATE TABLE orders_2025 (
    id INT PRIMARY KEY,
    user_id INT,
    order_amount DECIMAL(10,2)
);

CREATE TABLE orders_2026 (
    id INT PRIMARY KEY,
    user_id INT,
    order_amount DECIMAL(10,2)
);

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    country VARCHAR(50),
    city VARCHAR(50)
);

CREATE TABLE billing_logs (
    log_id INT PRIMARY KEY,
    user_id INT,
    fee DECIMAL(10,2)
);

INSERT INTO orders_2025 VALUES (1, 1001, 150.00), (2, 1002, 200.50);
INSERT INTO orders_2026 VALUES (1, 1001, 99.00),  (2, 1003, 300.00);

INSERT INTO customers VALUES 
(1, 'China', 'Beijing'), 
(2, 'China', 'Shanghai'), 
(3, 'China', 'Beijing'),
(4, 'USA', 'New York');

INSERT INTO billing_logs VALUES 
(1, 1001, 10.50), (2, 1001, 20.00), 
(3, 1002, 55.00), (4, 1003, 12.00);

DELIMITER //
CREATE PROCEDURE proc_test_hint(IN p_user_id INT)
BEGIN
    -- 仅做演示：查询特定用户的总费用
    SELECT SUM(fee) FROM billing_logs WHERE user_id = p_user_id;
END //
DELIMITER ;

Rows Hint 修正聚合节点基数估计

-- 【示例】强制修正聚合节点的基数估计为 100,000 行
kingbase=# EXPLAIN SELECT /*+ ROWS(billing_logs #100000) */ user_id, SUM(fee)
kingbase-# FROM billing_logs
kingbase-# GROUP BY user_id;
                               QUERY PLAN
-------------------------------------------------------------------------
 HashAggregate  (cost=525.60..528.10 rows=200 width=30)
   Group Key: user_id
   ->  Seq Scan on billing_logs  (cost=0.00..25.60 rows=100000 width=20)
(3 rows)

-- 【对照】使用默认估计（无 Hint）
kingbase=# EXPLAIN SELECT user_id, SUM(fee)
kingbase-# FROM billing_logs
kingbase-# GROUP BY user_id;
                              QUERY PLAN
-----------------------------------------------------------------------
 HashAggregate  (cost=33.40..35.90 rows=200 width=30)
   Group Key: user_id
   ->  Seq Scan on billing_logs  (cost=0.00..25.60 rows=1560 width=20)
(3 rows)

2.4 DISTINCT 并行查询

概念介绍：

KingbaseES V9R3C18 支持 DISTINCT 并行查询。在数据库开启并行查询（max_parallel_workers_per_gather > 0）且表具有足够并行度时，大数据量 DISTINCT 去重查询可利用多 CPU 核心并行执行，大幅提升执行效率。

实践步骤：

-- 准备测试数据
CREATE TABLE t_distinct (
    id INT,
    category VARCHAR(50),
    value INT
);

INSERT INTO t_distinct
SELECT generate_series(1, 1000000),
       CASE WHEN random() < 0.5 THEN 'A' ELSE 'B' END,
       (random() * 1000)::int;

ANALYZE;

-- 串行 DISTINCT
SET max_parallel_workers_per_gather = 0;

-- 执行时间：较慢（全表扫描+单线程去重）
kingbase=# EXPLAIN ANALYZE SELECT DISTINCT category FROM t_distinct;
                                                        QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=17935.00..17935.02 rows=2 width=2) (actual time=790.540..790.541 rows=2 loops=1)
   Group Key: category
   ->  Seq Scan on t_distinct  (cost=0.00..15435.00 rows=1000000 width=2) (actual time=0.152..57.707 rows=1000000 loops=1)
 Planning Time: 0.115 ms
 Execution Time: 790.570 ms
(5 rows)



-- 并行 DISTINCT
SET max_parallel_workers_per_gather = 4;

-- 执行计划： Gather → HashAggregate
-- 执行时间：显著缩短
kingbase=# EXPLAIN ANALYZE SELECT DISTINCT category FROM t_distinct;
                                                                    QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------
 Unique  (cost=11643.79..11643.81 rows=2 width=2) (actual time=336.111..337.656 rows=2 loops=1)
   ->  Sort  (cost=11643.79..11643.80 rows=4 width=2) (actual time=336.111..337.649 rows=6 loops=1)
         Sort Key: category COLLATE utf8_general_ci NULLS FIRST
         Sort Method: quicksort  Memory: 25kB
         ->  Gather  (cost=11643.33..11643.75 rows=4 width=2) (actual time=335.884..337.618 rows=6 loops=1)
               Workers Planned: 2
               Workers Launched: 2
               ->  HashAggregate  (cost=10643.33..10643.35 rows=2 width=2) (actual time=316.179..316.180 rows=2 loops=3)
                     Group Key: category
                     ->  Parallel Seq Scan on t_distinct  (cost=0.00..9601.67 rows=416667 width=2) (actual time=0.026..23.349 rows=333333 loops=3)
 Planning Time: 0.059 ms
 Execution Time: 337.697 ms
(12 rows)

2.5 DISTINCT + LIMIT 下推

概念介绍：

DISTINCT + LIMIT 优化是 V9R3C18 专为高重复率数据的去重场景设计的优化技术。对于 SELECT DISTINCT ... LIMIT n 语句，优化器将 LIMIT 值下推至 HashAgg 节点，在哈希表构建过程中监控唯一值数量，一旦达到阈值即停止扫描，实现提前终止，避免全表扫描的 I/O 和 CPU 开销。特别适用于高重复数据表。

实践步骤：

-- 准备高重复率数据（100 万行，仅约 11 个唯一值）
CREATE TABLE high_repeat (a int);
INSERT INTO high_repeat SELECT (random() * 10)::int FROM generate_series(1, 1000000);
ANALYZE;

-- 开启优化，执行计划显示 "Early Limit: 5"，表示 LIMIT 已下推
SET max_parallel_workers_per_gather = 0;
SET enable_hashagg_limit = on;

kingbase=# EXPLAIN ANALYZE SELECT DISTINCT a FROM high_repeat LIMIT 5;
                                                        QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=16925.00..16925.05 rows=5 width=4) (actual time=0.052..0.054 rows=5 loops=1)
   ->  HashAggregate  (cost=16925.00..16925.05 rows=5 width=4) (actual time=0.051..0.052 rows=5 loops=1)
         Group Key: a
         Early Limit: 5
         ->  Seq Scan on high_repeat  (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.044..0.045 rows=9 loops=1)
 Planning Time: 0.050 ms
 Execution Time: 0.071 ms
(7 rows)

-- 关闭优化
kingbase=# SET enable_hashagg_limit = off;
SET
kingbase=# EXPLAIN ANALYZE SELECT DISTINCT a FROM high_repeat LIMIT 5;
                                                            QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=16925.00..16925.05 rows=5 width=4) (actual time=137.067..137.068 rows=5 loops=1)
   ->  HashAggregate  (cost=16925.00..16925.05 rows=5 width=4) (actual time=137.065..137.066 rows=5 loops=1)
         Group Key: a
         ->  Seq Scan on high_repeat  (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.013..50.073 rows=1000000 loops=1)
 Planning Time: 0.083 ms
 Execution Time: 137.099 ms
(6 rows)

2.6 Memoize 参数化结果集缓存

概念介绍：

Memoize 是 KingbaseES 实现参数化结果集缓存的一种执行节点技术。在执行 NestLoop 及 SubPlan 查询时，Memoize 节点以外层相关数据作为 key，内层查询结果作为 value 进行缓存。当相同参数再次出现时，直接从缓存返回结果，无需重新扫描内层表，从而避免重复计算。

核心参数：

enable_memoize：控制 Memoize 节点的启用（ on/off/force ，默认 on）
memo_low_ratio：最低命中率阈值（默认 0.8），低于此值时 Memoize 自动切为"旁路模式"
memo_check_frequency：动态检查命中率的频率（默认 10000 次 miss）

实践步骤：

-- 开启 Memoize（默认已开启）
SET enable_memoize = force;

-- 创建测试表
CREATE TABLE t_orders (
    id INT PRIMARY KEY,
    customer_id INT,
    amount DECIMAL(10,2)
);

CREATE TABLE t_customers (
    id INT PRIMARY KEY,
    name VARCHAR(50)
);

INSERT INTO t_customers SELECT generate_series(1,1000), 'Customer_' || generate_series(1,1000);
INSERT INTO t_orders SELECT generate_series(1,100000),
    (random() * 999 + 1)::int,
    (random() * 1000)::decimal(10,2);
ANALYZE;

-- Memoize 生效的场景： NestLoop 中的参数化路径
-- 外层 t_orders(100000 行) 关联内层 t_customers(1000 行)
-- 相同 customer_id 会重复出现，Memoize 缓存后避免重复扫描 t_customers

kingbase=# EXPLAIN (ANALYZE, BUFFERS)
kingbase-# SELECT * FROM t_orders o, t_customers c
kingbase-# WHERE o.customer_id = c.id;
                                                                  QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.29..4335.38 rows=100000 width=20) (actual time=0.019..32.277 rows=100000 loops=1)
   Buffers: shared hit=3541
   ->  Seq Scan on t_orders o  (cost=0.00..1544.00 rows=100000 width=14) (actual time=0.005..4.936 rows=100000 loops=1)
         Buffers: shared hit=544
   ->  Memoize  (cost=0.29..0.30 rows=1 width=6) (actual time=0.000..0.000 rows=1 loops=100000)
         Cache Key: o.customer_id
         Cache Mode: logical
         Hits: 99001  Misses: 999  Evictions: 0  Overflows: 0  Skips: 0  Memory Usage: 104kB
         Buffers: shared hit=2997
         ->  Index Scan using t_customers_pkey on t_customers c  (cost=0.28..0.29 rows=1 width=6) (actual time=0.001..0.001 rows=1 loops=999)
               Index Cond: (id = o.customer_id)
               Buffers: shared hit=2997
 Planning Time: 0.179 ms
 Execution Time: 35.341 ms
(14 rows)

2.7 代价惩罚与扩展统计信息

概念介绍：

代价惩罚：V9R3C18 支持根据 NestLoopJoin/MergeJoin 慢 SQL 特征，判断是否施加代价惩罚，引导优化器避开性能较差的执行计划，提升整体查询效率。
扩展统计信息：优化器除了单列统计信息外，还基于函数依赖与多列 MCV（Most Common Values）统计信息，优化包含 IN/ANY/ALL 条件的查询执行计划，有效提升基数估计准确性与优化器决策能力。

实践步骤：

-- 创建多列统计信息
CREATE STATISTICS s1 (dependencies) ON col1, col2 FROM t_batch;
CREATE STATISTICS s2 (mcv) ON col1, col2 FROM t_batch;

-- 查看扩展统计信息
kingbase=# SELECT * FROM sys_stats_ext;
 schemaname | tablename | statistics_schemaname | statistics_name | statistics_owner |  attnames   | kinds | n_distinct | dependencies | most_common_vals | most_common_val_nulls | most_common_freqs | most_common_base_freqs
------------+-----------+-----------------------+-----------------+------------------+-------------+-------+------------+--------------+------------------+-----------------------+-------------------+------------------------
 public     | t_batch   | public                | s1              | system           | {col1,col2} | {f}   |            |              |                  |                       |                   |
 public     | t_batch   | public                | s2              | system           | {col1,col2} | {m}   |            |              |                  |                       |                   |
(2 rows)

关于 KingbaseES MySQL 兼容版本性能相关的变更我们就先介绍到这里。

2026 金仓数据库产品体验官召集令

无论你是开发者、DBA，还是数据库爱好者，只要你对数据库技术有热情、愿意动手实践与分享，诚邀你加入"数据库平替用金仓"的体验官阵营！

⏰ 本期活动时间：2026 年 6 月 18 日 — 7 月 18 日

三步解锁体验官。

① 下载部署

前往金仓官网 (https://www.kingbase.com.cn/download.html) 获取安装包。

KingbaseES 数据库安装包 (MySQL兼容) — V9R3C18

此版本全方位升级，核心强化 MySQL 全栈兼容，实现业务无缝迁移。

② 深度体验（开发者 & DBA 双通道）

围绕以下金仓数据库 MySQL 兼容特性撰写博文（可自由选择多个特性进行体验）：

开发者体验方向

MySQL 语法兼容：体验零值日期、注释、CASE 类型隐式转换、字段位置调整、RENAME USER/TABLE、PREPARE/EXECUTE 等 MySQL 常用语法兼容。
JSON 与函数兼容：测试 JSON_OVERLAPS、JSON 操作符 -> / ->> 优先级，以及 INSERT、LEFT、quote、FORMAT、time format 等函数能力。
驱动与接口应用：使用 MySQL 原生驱动连接 KES，体验 MySQL C API 兼容接口，以及 GOKB 多主机智能连接、网络超时配置和自增列 ID 获取功能。
查询与写入优化：测试 OR Expansion、QueryMapping、Hint、DISTINCT 并行与 LIMIT 下推、Memoize 参数化结果集缓存，以及多 VALUES INSERT 批量写入，观察性能提升幅度。

DBA 体验方向

高可用集群运维：体验读写分离集群扩容、重建备库时的克隆同步速率控制，以及主库故障下并行检测、选举与升主流程优化。
备份恢复：测试全量、差异、文件增量的备份与恢复，以及备份集合并形成永久增量备份的策略管理。
故障恢复与日志解析：体验智能故障恢复模式、主库变迁历史记录，以及解析重做日志中 DDL 信息并动态更新数据字典的能力。
运维工具链：测试 kbinspect 一站式健康检查、sys_guc 参数批量修改、uninstall.sh 集群卸载及 HA-Log 故障信息自动收集分析能力。

③ 发布图文

采用 【金仓数据库产品体验官】+ 自拟标题，带双话题标签 #数据库就用金仓 #金仓产品体验官，发布至金仓社区博客专区或者 CSDN 博客专区。

更多活动细节请参考活动贴：

https://bbs.kingbase.com.cn/forumDetail?articleId=89b65cfa122a2a42ff148fa3bcc3099d

#数据库平替用金仓 #金仓产品体验官

Have a nice day ~ ☕

🌻 相关阅读 ▼

👉 这里有得聊

如果你对国产基础软件（操作系统、数据库、中间件）、AI Agent、Vibe Coding、OpenClaw 、Hermes Agent 等感兴趣，欢迎关注微信公众号：「少安事务所」。如果这篇文章为你带来了灵感或启发，请帮忙『点赞、转发、推荐』，感谢！ღ( ´･ᴗ･` )~

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

文章被以下合辑收录

少安事务所（2026）（共49篇）

少安事务所2026

金仓数据库 V9R3C18 MySQL 兼容版体验(性能篇)

01. 新版本速览：KES V9R3C18 MySQL兼容版

QueryMapping能力增强

Hint执行控制增强

查询规则优化

DISTINCT处理能力增强

执行计划效率提升

扩展统计信息完善

分区表查询优化

02. KingbaseES V9R3C18 实践体验

2.1 OR Expansion

2.2 QueryMapping 增强

2.3 Hint 执行控制增强

2.4 DISTINCT 并行查询

2.5 DISTINCT + LIMIT 下推

2.6 Memoize 参数化结果集缓存

2.7 代价惩罚与扩展统计信息

2026 金仓数据库产品体验官召集令

① 下载部署

② 深度体验（开发者 & DBA 双通道）

③ 发布图文

文章被以下合辑收录

评论