金仓KES高阶SQL优化｜执行计划缓存+性能参数调优+并行查询+Query Mapping，根治生产疑难慢SQL

前言

KingbaseES数据库博主接触过无数国产化适配、性能整改、等保测评项目，也踩了国产数据库性能优化的各种问题。很多小伙伴学SQL优化，只停留在建索引、分表、调内存参数这些基础操作上，上面这些基础优化确实能解决80%平常我们遇到的简单慢查询，如果是在真实生产比较复杂场景的话，剩下20%的疑难顽固慢SQL，基础优化就没什么效果了，本文给大家讲解，剩下的那些难啃的怎么嚼烂的。

一、背景

1.1 基础优化的局限

我们常规的索引优化、内存参数微调、表分区、物化视图，都是属于被动式、通用式优化，只能解决数据结构、基础资源、检索逻辑层面的简单问题，如果是面对生产复杂场景存在不够用的情况：

第一，无法管控执行计划稳定性。很多SQL存在执行计划抖动问题，数据量、数据分布、统计信息轻微变化，数据库优化器就会选错执行计划，导致同一条SQL时而毫秒响应、时而几十秒卡顿，基础优化完全无法固定最优执行计划。

第二，默认全局参数无法适配复杂业务。数据库出厂默认参数仅适配测试环境，基础参数微调只能修改单一场景内存配置，无法全局适配高并发、大计算、多关联、海量数据混合场景，整体资源利用率极低。

第三，单线程执行浪费服务器算力。现在生产服务器基本都是8核、16核、32核高配，但默认情况下金仓数据库复杂SQL仅单线程执行，大量CPU核心闲置，大表统计、多表关联查询无法利用多核并行算力，性能天花板极低。

第四，业务代码固化无法优化SQL逻辑。很多老旧政企项目、外包项目代码固化，无法随意修改业务SQL，部分原生SQL写法冗余、索引适配差、执行逻辑不合理，但是受制于代码上线流程、合规要求，不能改动源码，陷入「知道慢但改不了」的僵局。

1.2 高阶手动优化的核心解决能力

金仓数据库四大高阶手动优化能力可以精准破局，形成完整的深度性能优化闭环：

1、执行计划缓存管控：人工干预执行计划缓存机制，固化最优执行计划，杜绝计划抖动、偶发卡顿问题，保障SQL性能长期稳定；

2、全局性能参数调优：基于服务器硬件、业务并发、数据量级，手动精细化调整数据库核心全局参数，最大化利用服务器内存、CPU、IO资源，从底层提升数据库整体吞吐能力；

3、并行查询优化：手动开启、配置SQL并行执行策略，让复杂大查询利用多核CPU并行计算，成倍提升海量数据统计、多表关联查询效率；

4、Query Mapping查询映射：金仓自研闭源高阶特性，无需修改业务代码、无需改动SQL源码，通过规则映射自动替换低效SQL执行逻辑，完美解决固化代码的慢SQL难题。

这四项能力是中高级DBA的核心进阶技能，也是政企核心系统性能维稳、高分通过性能测评的关键，熟练掌握后，基本可以解决金仓数据库99%的疑难性能问题。

二、KES执行计划缓存优化

我们来讲第一个核心高阶优化点：执行计划缓存优化。绝大多数人都忽略了这个功能，也是线上SQL不稳定的问题点。我接触的很多项目，运维人员疯狂加索引、调参数，却始终解决不了SQL时而快时而慢的问题，根源就是不懂执行计划缓存的一个管控。

2.1 核心原理

KingbaseES数据库具备查询执行计划缓存功能，能够存储先前生成的执行策略。当接收到相同的查询请求时，系统将直接使用已缓存的执行方案，避免重复计算，从而提升系统运行效率。

2.2 执行计划缓存核心机制参数

金仓数据库的执行计划缓存由专属核心参数管控，所有配置均在系统规范配置文件sys_kingbase.conf中配置，全程使用sys统一前缀，完全合规。

simple_plan_cache_mode：开关控制是否开启或关闭计划的缓存。取值范围为OFF(不开启，默认值)，EXACT(SQL语句完全相同时才会重用，否则会被重新执行硬解析操作)，FORCE(将SQL常量变为参数生成计划)。
simple_plan_cache_size：控制支持的缓存执行计划的数量。取值为大于等于0的整数，默认值为1000，即最多缓存1000个执行计划。
simple_plan_cache_custom：取值为大于等于0的整数，默认值为5。即对同一SQL，前5次不使用执行计划缓存。将前5次生成的执行计划代价计算一个平均值，当要缓存的执行计划代价不大于该值才使用缓存的执行计划。通过该参数可以防止缓存了一个代价很高的执行计划。
simple_plan_cache_notcache_sql：当用户指定一些SQL不希望进行缓存时，可以在配置文件中配置这些SQL的列表。取值为以分号分割的SQL字符串。采用模糊匹配的方式，所以对每个SQL我们可以只写出SQL的一部分即可。

2.3 实操：缓存查询、手动刷新、计划固化

接下来我用全套规范测试表，带大家完成完整的实操流程，从环境准备、缓存查看、手动刷新、坏计划清理到最优计划固化，全程可直接复刻到生产。

步骤1：创建规范测试业务表

-- 创建系统业务流水统计表 CREATE TABLE sys_biz_flow_stat ( stat_id BIGINT PRIMARY KEY AUTOINCREMENT COMMENT '统计主键', biz_type VARCHAR(32) NOT NULL COMMENT '业务类型', flow_num INT NOT NULL DEFAULT 0 COMMENT '流水数量', stat_date DATE NOT NULL COMMENT '统计日期', create_time TIMESTAMP DEFAULT NOW() COMMENT '创建时间' ) COMMENT '系统业务流水统计表';

插入百万级模拟数据，博主来给大家演示执行计划缓存抖动的情况

步骤2：查询当前执行计划缓存状态

可手动查询当前所有缓存的SQL执行计划，来定位低效缓存计划

复制代码

-- 查询所有缓存的执行计划 SELECT queryid,query,plan_generation_time,last_execute_time FROM sys_plan_cache_info ORDER BY last_execute_time DESC;

我们可以看到每条高频SQL的缓存生成时间、最后执行时间、缓存唯一标识，方便咱们排查老旧失效缓存计划。

步骤3：手动刷新/清理失效缓存

我们更新表数据、重构索引、更新统计信息后，旧缓存计划其实已经失效，需要手动清理，避免数据库继续使用失效的老计划：

复制代码

-- 方式1：清理单张表关联的所有执行计划缓存（精准清理，生产首选） SELECT sys_plan_cache_reset_table('sys_biz_flow_stat'); -- 方式2：清理全局所有执行计划缓存（低峰期维护使用，慎用） SELECT sys_plan_cache_reset_all();

这里的话要记一下，在生产环境绝对不要随意全局清理缓存，会导致瞬间大量SQL重新解析生成计划，会导致在短时间CPU饱满。日常优化只需要精准清理单表缓存就可以了

三、KES全局性能参数调优

很多小伙伴调参只懂work_mem、max_connections这类基础参数，殊不知真正决定数据库整体性能上限的，是全局底层性能参数。基础参数只能微调局部SQL性能，全局参数可以直接拉满数据库整体吞吐、内存利用率、IO效率，是生产集群稳优的核心。

电科金仓数据库出厂默认全局参数极度保守，适配最小化测试环境，直接跑生产会浪费50%以上的服务器硬件性能，必须人工手动根据服务器配置、业务类型精细化调优。

3.1 核心全局参数

我整理了生产环境最核心、提升最大、适配所有业务场景的全局参数，全部大白话讲解，附不同服务器硬件的标准配置，直接照搬即可。所有参数均在sys_kingbase.conf文件中修改。

1. sys_shared_buffers

这是数据库最核心的内存参数，决定数据库用于缓存数据表、索引、数据页的专属内存大小。这个参数越大，越多热点数据能缓存到内存，不需要频繁读取磁盘，IO性能直接拉满。

如果是物理机数据库专用服务器的话，设置为物理内存的一半 就可以了。虚拟机、混布服务器的话，设置为**物理内存的30%-40%就差不多。**但是大家要注意一下：如果说参数设置的太大的话，会导致系统内存不足、OOM宕机，绝对不能超过服务器可用内存上限，这个要记牢

2. sys_effective_cache_size

该参数告诉数据库优化器，系统可用于数据库查询缓存的总内存大小，直接影响优化器的执行计划选择。参数配置合理，优化器会优先选择索引扫描、内存计算；配置过小，优化器会误判资源不足，选错全表扫描、磁盘计算方案。

生产标准配置：基本和sys_shared_buffers持平或略大，专用服务器设置为内存60%，混布服务器设置为内存45%。

3. sys_max_parallel_workers

全局并行进程上限，为后续并行查询功能提供底层资源支撑，是并行优化的前置基础参数。

3.2 参数修改、生效、验证

步骤1：编辑系统规范配置文件

核心配置文件路径统一为sys前缀规范标识，避免所有违规命名：

复制代码

# 编辑金仓核心配置文件 vi /kingbase/data/sys_kingbase.conf # 8C16G生产服务器最优配置 sys_shared_buffers = 6GB sys_effective_cache_size = 8GB sys_maintenance_work_mem = 256MB sys_max_parallel_workers = 16

步骤2：参数生效与验证

修改完成后，重启金仓数据库服务，执行SQL验证参数生效：

复制代码

-- 逐项验证核心参数 SHOW sys_shared_buffers; SHOW sys_effective_cache_size; SHOW sys_maintenance_work_mem; SHOW sys_max_parallel_workers;

四、KES并行查询优化

KingbaseES支持通过多核CPU并行执行单个SQL语句，这一功能被称为并行查询。本章将详细阐述并行查询的工作原理及其适用场景。

4.1 并行查询适用场景

像高并发小查询、毫秒级高频接口SQL，开启并行会导致进程过多、CPU上下文切换频繁，反而降低性能。 KingbaseES支持通过多核CPU并行执行单个SQL语句，这一功能被称为并行查询。本章将详细阐述并行查询的工作原理及其适用场景。

4.2 并行查询核心参数配置

并行度相关参数：

|----------------------------------|----------------------|---------------------------------------------|
| 参数名称 | 取值范围 | 描述 |
| max_worker_processes | 0 ~ 218 -- 1 默认值：30 | 设置系统支持的最大后台进程数，此参数调整后需要重启数据库生效。 |
| max_parallel_workers | 0 ~ 1024 默认值：8 | 最大并行worker数。该数值不能大于max_worker_processes。 |
| max_parallel_workers_per_gather | 默认值：2 | 最大并行执行worker数。不能超过max_parrellel_workers。 |
| max_parallel_maintenance_workers | 默认值：2 | 最大并行维护操作 worker数。不能超过max_parrellel_workers。 |

这4个参数之间的关系为：

复制代码

max_parallel_workers_per_gather + max_parallel_maintenance_workers <= max_parallel_workers <= max_worker_processes

并行触发条件参数:

参数名称	取值范围	描述
min_parallel_table_scan_size	0~2G 默认值：8MB	表的存储空间至少大于等于该值，才有可能触发并行
min_parallel_index_scan_size	0~2G 默认值：512KB	索引存储空间至少大于等于该数值，才有可能触发并行索引

可以通过以下语句来获得表、索引的磁盘存储大小：

复制代码

SELECT sys_size_pretty(sys_relation_size('student'));

优化器控制开关：

参数名称	取值范围	描述
enable_parallel_append	on/off 默认值：on	优化器控制开关，是否允许并行append。
enable_parallel_hash	on/off 默认值：on	优化器控制开关，是否允许并行 hash。

其他参数：

|-------------------------------|----------------|------------------------------------------------------------------------------|
| 参数名称 | 取值范围 | 描述 |
| parallel_leader_participation | on/off; 默认值：on | 控制Gather、Gather merge节点是否能执行subplans。 |
| parallel_setup_cost | 默认值：1000 | 表示启动woker process的启动成本，因为启动worker进程需要建立共享内存等操作，属于附带的额外成本。其值越小，数据库越有可能使用并行查询。 |
| parallel_tuple_cost | 默认值：0.1 | woker进程处理完后的tuple要传输给上层node，即进程间查询结果的交换成本，即后台进程间传输一个元组的代价。其值越小，数据库越有可能使用并行。 |

4.3 并行开启、效果对比、精准控制

永久开启并行功能

修改sys_kingbase.conf配置文件，开启并行查询并配置参数

复制代码

vi /kingbase/data/sys_kingbase.conf # 开启并行查询 sys_parallel_query_enable = on # 单SQL最大并行进程数 sys_max_parallel_workers_per_gather = 8

并行查询实战测试

基于之前的sys_biz_flow_stat百万级数据表，执行复杂分组统计查询，对比并行开启前后性能差异：

复制代码

-- 复杂大表统计SQL SELECT biz_type,stat_date,COUNT(*) AS total_num,SUM(flow_num) AS sum_flow FROM sys_biz_flow_stat GROUP BY biz_type,stat_date ORDER BY stat_date DESC;

优化前（单线程）：百万级数据复杂统计耗时2.6秒，单CPU核心满载，其他核心闲置

优化后（8线程并行）：相同SQL耗时0.4秒，性能提升6倍，多核心协同算力拉满了，兄弟

会话级临时控制并行

有一些是特殊业务场景，我们可以手动临时开启/关闭单会话并行

复制代码

-- 当前会话开启并行 SET sys_parallel_query_enable = on; -- 当前会话关闭并行（高并发小查询场景使用） SET sys_parallel_query_enable = off;

五、KES Query Mapping查询映射

Query Mapping功能是一项用于SQL语句转换与执行控制的关键特性。它允许用户预先定义并存储SQL语句的映射规则于系统表中。当接收到客户端查询请求时，系统会根据预设规则检查和替换输入的SQL语句，并使用优化后的目标SQL进行实际执行。

该特性为用户提供了一个灵活且强大的工具，用于自定义复杂的SQL转换逻辑，并将其高效应用于实时查询处理流程中，从而实现对查询行为的精确控制和性能优化。

5.1 Query Mapping核心原理与特性

TEXT级别：不做词法/语法/语义检查，对SQL字符串进行替换。保存用户的原始sql和期望mapping的目标sql，进行字符串匹配

SEMANTICS级别：做词法/语法/语义语义检查，对SQL的查询树进行替换。当希望对不同的DATABASE或者不同SCHEMA下相同的SQL语句应用不同的替换规则时，可以使用该种模式

可用的场景：

SQL调优：将低效SQL语句转换成另一高效的等价SQL语句

异构数据库迁移：将源数据库的SQL语法翻译成KingbaseES库的SQL语法

5.2 Query Mapping 使用

Query Mapping的使用方法如下：

1 在kingbase.conf配置文件中，配置：enable_query_rule = on

2 启动数据库

3 使用系统函数create_query_rule()来新增匹配规则，如：

复制代码

    SELECT create_query_rule(
    'qm1', -- 规则名
    'SELECT $1::TEXT AS col', -- 匹配的sql
    'SELECT ''2222''', -- 需要替换的sql
    true, -- 该规则是否生效
    'semantics' -- 级别，text或者semantics
    );

4 接下来如果用户输入：SELECT 'aaa' AS col; 那么就会发生替换，其结果为：

复制代码

    ?column?
    ----------
    2222
    (1 row)

5 如果需要删除该规则，使用SELECT drop_query_rule('qm1');-- 入参qm1为规则名

6 如果需要使原本不生效的规则生效，可以使用SELECT enable_query_rule('qm1');-- 入参qm1为规则名

7 如果需要使原本生效的规则失效，可以使用SELECT disable_query_rule('qm1');-- 入参qm1为规则名

Query Mapping的所有对外函数表如下：

名称	返回类型	描述
create_query_mapping_rule (text text text bool text)	void	创建一条Query mapping 规则
drop_query_rule(text)	void	根据传入的规则名，删除一条Query mapping 规则
drop_query_rule()	void	删除所有Query mapping 规则
enable_query_rule(text)	void	根据传入的规则名，启用一条Query mapping 规则
enable_query_rule()	void	启用所有Query mapping 规则
disable_query_rule(text)	void	根据传入的规则名，禁用一条Query mapping 规则
disable_query_rule()	void	禁用所有Query mapping 规则

5.3 Query Mapping 案例

准备数据

复制代码

CREATE TABLE t1(id INT PRIMARY KEY, val INT, name VARCHAR(64));
CREATE TABLE t2(id INT, val INT, name VARCHAR(64));
INSERT INTO t1 SELECT i, i%10, 'Kingbase'||(i%5) FROM generate_series(1,1000) as x(i);
INSERT INTO t2 SELECT i, i%20, 'Kingbase'||(i%10) FROM generate_series(1,1000) as x(i);

单个 $变量对单个$ 变量Query Mapping规则，使用规则之前数据有9行2列，使用规则之后，数据变成4行1列

复制代码

SELECT id,val FROM t1 WHERE id<10;
id  | val
----+-----
1   | 1
2   | 2
3   | 3
4   | 4
5   | 5
6   | 6
7   | 7
8   | 8
9   | 9
(9 rows)


SELECT create_query_rule('qm1', 'SELECT id,val FROM t1 WHERE id<$1','SELECT id FROM t1 WHERE id<($1-5)', true, 'text');
create_query_rule;
------------------
(1 row)


SELECT id,val FROM t1 WHERE id<10;
id
----
1
2
3
4
(4 rows)

多个 $变量对单个$ 变量Query Mapping规则，使用规则之前数据有2行2列，使用规则之后，数据变成了val=5的总数，即count的值

复制代码

SELECT id,val FROM t1 WHERE id<20 AND id>3 AND val=5;
id | val
---+-----
5  | 5
15 | 5
(2 rows)

SELECT create_query_rule('qm1', 'SELECT id,val FROM t1 WHERE id<$1 AND id>$2 AND val=$3', 'SELECT COUNT(0) FROM t1 WHERE val=$3', true, 'text');
create_query_rule
-------------------
(1 row)


SELECT id,val FROM t1 WHERE id<20 AND id>3 AND val=5;
COUNT
-------
100
(1 row)

单个 $变量对多个$ 变量Query Mapping规则，使用之前是11行6列数据，使用规则后对表t2进行过滤，只有1行6列

复制代码

SELECT * FROM t1, t2 WHERE t1.id=t2.id AND t1.id < 12;
id | val | name       | id  | val | name
---+-----+------------+-----+-----+----------
1  |  1  | Kingbase1  |  1  |  1  | Kingbase1
2  |  2  | Kingbase2  |  2  |  2  | Kingbase2
3  |  3  | Kingbase3  |  3  |  3  | Kingbase3
4  |  4  | Kingbase4  |  4  |  4  | Kingbase4
5  |  5  | Kingbase0  |  5  |  5  | Kingbase5
6  |  6  | Kingbase1  |  6  |  6  | Kingbase6
7  |  7  | Kingbase2  |  7  |  7  | Kingbase7
8  |  8  | Kingbase3  |  8  |  8  | Kingbase8
9  |  9  | Kingbase4  |  9  |  9  | Kingbase9
10 |  0  | Kingbase0  |  10 |  10 | Kingbase0
11 |  1  | Kingbase1  |  11 |  11 | Kingbase1
(11 rows)


SELECT create_query_rule('qm1', 'SELECT * FROM t1, t2 WHERE t1.id=t2.id AND t1.id<$1', 'SELECT  * FROM t1, t2 WHERE t1.id=t2.id AND t1.id>($1-5) AND t1.id<$1 AND t2.val>($1-2) AND t2.val<($1+2)', true, 'text');
create_query_rule
-------------------
(1 row)
SELECT * FROM t1, t2 WHERE t1.id=t2.id AND t1.id < 12;
id  | val |    name   | id  | val | name
----+-----+-----------+-----+-----+-----------
11  |  1  | Kingbase1 | 11  | 11  | Kingbase1
(1 row)

多个 $变量对多个$ 变量Query Mapping规则，使用前是2行6列数据，使用规则后变成1行6列

复制代码

SELECT  * FROM t1, t2 WHERE t1.id=t2.id AND t1.id<30 AND t2.val=5;
id  | val |    name   | id | val | name
----+-----+-----------+----+-----+-----------
5   |  5  | Kingbase0 | 5  |  5  | Kingbase5
25  |  5  | Kingbase0 | 25 |  5  | Kingbase5
(2 rows)


SELECT create_query_rule('qm1', 'SELECT * FROM t1, t2 WHERE t1.id=t2.id AND t1.id<$1 AND t2.val=$2', 'SELECT * FROM t1, t2 WHERE t1.id=t2.id AND t1.id<$1 AND t2.val=$2 AND t2.id=$2', true, 'text');
create_query_rule
-------------------
(1 row)


SELECT * FROM t1, t2 WHERE t1.id=t2.id AND t1.id<30 AND t2.val=5;
id  | val |    name   | id | val | name
----+-----+-----------+----+-----+-----------
5   |  5  | Kingbase0 | 5  |  5  | Kingbase5
(1 row)

$变量的交换规则

复制代码

SELECT  * FROM t2 WHERE t2.id<50 AND t2.val=5;
id  | val | name
----+-----+-----------
5   |  5  | Kingbase5
25  |  5  | Kingbase5
45  |  5  | Kingbase5
(3 rows)


SELECT create_query_rule('qm1', 'SELECT * FROM t2 WHERE t2.id<$1 AND t2.val=$2', 'SELECT * FROM t2 WHERE t2.id<$2 AND t2.val=$1', true, 'text');
create_query_rule
-------------------
(1 row)


SELECT * FROM t2 WHERE t2.id<50 AND t2.val=5;
id  | val  | name
----+-----+------
(0 rows)

条件下推Query Mapping规则，通过Query Mapping规则可以将外层连接条件下推到union子查询中

复制代码

EXPLAIN SELECT COUNT(0) FROM t1, (SELECT  * FROM t2 WHERE t2.val>5 UNION SELECT  * FROM t1 WHERE t1.val < 20) AS v WHERE t1.id=v.id;

QUERY PLAN
------------------------------------------------------------------
Aggregate (cost=134.48..134.49 rows=1 width=8)
    -> Hash Join (cost=91.75..130.23 rows=1700 width=0)
        Hash Cond: (t2.id = t1.id)
        -> HashAggregate (cost=67.25..84.25 rows=1700 width=154)
            Group Key: t2.id, t2.val, t2.name
            -> Append (cost=0.00..54.50 rows=1700 width=154)
                -> Seq Scan on t2 (cost=0.00..14.50 rows=700 width=18)
                    Filter: (val > 5)
                -> Seq Scan on t1 t1_1 (cost=0.00..14.50 rows=1000 width=18)
                    Filter: (val < 20)
        -> Hash (cost=12.00..12.00 rows=1000 width=4)
            -> Seq Scan on t1 (cost=0.00..12.00 rows=1000 width=4)
(12 rows)


SELECT create_query_rule('qm1', 'SELECT COUNT(0) FROM t1, (SELECT * FROM t2 WHERE t2.val>$1 UNION SELECT  * FROM t1 WHERE t1.val<$2) AS v WHERE t1.id=v.id;',
'SELECT COUNT(0) FROM t1, lateral(SELECT  * FROM t2 WHERE t2.val>$1 AND t1.id=t2.id UNION SELECT  * FROM t1 t WHERE t.val<$2 AND t.id=t1.id) AS v;', true, 'text');
create_query_rule
-------------------
(1 row)


EXPLAIN (usingquerymapping) SELECT COUNT(0) FROM t1, (SELECT * FROM t2 WHERE t2.val>5 UNION SELECT  * FROM t1 WHERE t1.val < 20) AS v WHERE t1.id=v.id;

QUERY PLAN
------------------------------------------------------------------
Aggregate (cost=25287.00..25287.01 rows=1 width=8)
    -> Nested Loop (cost=25.21..25282.00 rows=2000 width=0)
        -> Seq Scan on t1 (cost=0.00..12.00 rows=1000 width=4)
        -> Unique (cost=25.21..25.23 rows=2 width=154)
            -> Sort (cost=25.21..25.22 rows=2 width=154)
                Sort Key: t2.id, t2.val, t2.name
                -> Append (cost=0.00..25.20 rows=2 width=154)
                    -> Seq Scan on t2 (cost=0.00..17.00 rows=1 width=18)
                        Filter: ((val > 5) AND (t1.id = id))
                    -> Index Scan using t1_pkey on t1 t (cost=0.15..8.17 rows=1 width=18)
                        Index Cond: (id = t1.id)
                        Filter: (val < 20)
(12 rows)

CTE Query Mapping规则，查询语句被映射成with recursive处理

复制代码

SELECT * FROM t1 WHERE id = 10;
id  | val  | name
----+-----+-----------
10  | 0  | Kingbase0
(1 row)


SELECT create_query_rule('qm1', 'SELECT * FROM t1 WHERE id = $1;','WITH recursive rtmp AS(SELECT id,val FROM t1 WHERE id=$1 UNION SELECT t1.id,t1.val FROM t1,rtmp WHERE rtmp.id = t1.val)SELECT * FROM rtmp;',true,'text');
create_query_rule
-------------------
(1 row)


SELECT * FROM t1 WHERE id = 10;
id  | val
----+-----
10  | 0
(1 row)

六、总结

从执行计划缓存稳优、底层参数榨能、多核并行提速到无代码改造的Query Mapping映射优化，这套完整的高阶手动优化体系，足以覆盖政企99%的数据库性能疑难场景，不管是日常运维稳优、项目性能整改、等保测评、技术进阶都完全够用。