kingbase sql 回表优化案例

同事找我优化SQL,同一条SQL语句LIKE过滤条件不同,执行时间差别很多,废话不说安排一下。
LIKE过滤条件执行快的SQL和执行计划:
EXPLAIN ANALYZE
SELECT case_id,
cate_id,
cate_name,
view_url,
proc_ins_id,
create_user_id,
current_user_id,
title,
emergency,
dept_id,
handler_id,
handle_date,
create_date,
end_date,
proc_ins_state,
hint
FROM AAAAAA H
WHERE handler_id = '8feae683-f741-45de-b430-7db24b4f7660'
AND title like '%通报%'
ORDER BY handle_date desc nulls last, emergency DESC; Sort (cost=83260.22..83263.92 rows=1479 width=463) (actual time=203.872..205.642 rows=1750 loops=1)
Sort Key: H.handle_date DESC NULLS LAST, P.emer_level DESC
Sort Method: quicksort Memory: 968kB
-> Gather (cost=12513.91..83182.35 rows=1479 width=463) (actual time=146.637..204.384 rows=1750 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Hash Join (cost=11513.91..69536.90 rows=616 width=452) (actual time=140.984..182.745 rows=583 loops=3)
Hash Cond: (P.cate_id = C.id)
-> Parallel Hash Join (cost=11506.98..69528.32 rows=616 width=408) (actual time=140.808..182.364 rows=583 loops=3)
Hash Cond: (H.proc_ins_id = P.id)
-> Parallel Bitmap Heap Scan on ccccccccccc H (cost=443.78..58432.47 rows=12438 width=156) (actual time=6.527..46.555 rows=10375 loops=3)
Recheck Cond: (handler_id = '8feae683-f741-45de-b430-7db24b4f7660'::bpcharbyte)
Filter: ((state = 'A'::bpcharbyte) AND (category = 'H'::bpcharbyte))
Heap Blocks: exact=2799
-> Bitmap Index Scan on PROC_INS_HANDLERS_HANDLER_ID (cost=0.00..436.31 rows=29851 width=0) (actual time=7.405..7.405 rows=31125 loops=1)
Index Cond: (handler_id = '8feae683-f741-45de-b430-7db24b4f7660'::bpcharbyte)
-> Parallel Hash (cost=10935.95..10935.95 rows=10180 width=289) (actual time=132.111..132.112 rows=4266 loops=3)
Buckets: 32768 Batches: 1 Memory Usage: 4480kB
-> Parallel Seq Scan on ddddddddddddd P (cost=0.00..10935.95 rows=10180 width=289) (actual time=0.049..126.563 rows=4266 loops=3)
Filter: ((title)::text ~~ '%通报%'::text)
Rows Removed by Filter: 160050
-> Hash (cost=4.19..4.19 rows=219 width=81) (actual time=0.079..0.080 rows=221 loops=3)
Buckets: 1024 Batches: 1 Memory Usage: 33kB
-> Seq Scan on eeeeeeeeeeeee C (cost=0.00..4.19 rows=219 width=81) (actual time=0.016..0.040 rows=221 loops=3)
SubPlan 1
-> Index Scan using wf_act_instances_PKEY on wf_act_instances (cost=0.43..8.45 rows=1 width=14) (actual time=0.011..0.012 rows=0 loops=1750)
Index Cond: (id = H.act_ins_id)
Planning Time: 1.185 ms
Execution Time: 205.909 ms
LIKE过滤条件执行慢的SQL和执行计划:
EXPLAIN ANALYZE
SELECT case_id,
cate_id,
cate_name,
view_url,
proc_ins_id,
create_user_id,
current_user_id,
title,
emergency,
dept_id,
handler_id,
handle_date,
create_date,
end_date,
proc_ins_state,
hint
FROM AAAAAA H
WHERE handler_id = '8feae683-f741-45de-b430-7db24b4f7660'
AND title like '%表扬%'
ORDER BY handle_date desc nulls last, emergency DESC; Sort (cost=21036.84..21036.85 rows=3 width=463) (actual time=2023.884..2023.948 rows=139 loops=1)
Sort Key: H.handle_date DESC NULLS LAST, P.emer_level DESC
Sort Method: quicksort Memory: 97kB
-> Gather (cost=1449.85..21036.82 rows=3 width=463) (actual time=9.150..2023.615 rows=139 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Nested Loop (cost=449.85..20011.17 rows=1 width=452) (actual time=25.891..2010.559 rows=46 loops=3)
-> Nested Loop (cost=449.71..20010.66 rows=1 width=408) (actual time=25.841..2010.065 rows=46 loops=3)
-> Parallel Seq Scan on ddddddddddddd P (cost=0.00..10935.95 rows=20 width=289) (actual time=0.616..138.214 rows=185 loops=3)
Filter: ((title)::text ~~ '%表扬%'::text)
Rows Removed by Filter: 164131
-> Bitmap Heap Scan on ccccccccccc H (cost=449.71..453.73 rows=1 width=156) (actual time=10.097..10.097 rows=0 loops=556)
Recheck Cond: ((proc_ins_id = P.id) AND (handler_id = '8feae683-f741-45de-b430-7db24b4f7660'::bpcharbyte))
Filter: ((state = 'A'::bpcharbyte) AND (category = 'H'::bpcharbyte))
Heap Blocks: exact=29
-> BitmapAnd (cost=449.71..449.71 rows=1 width=0) (actual time=10.093..10.093 rows=0 loops=556)
-> Bitmap Index Scan on PUBLIC_ccccccccccc_INDEX_7 (cost=0.00..5.68 rows=166 width=0) (actual time=0.042..0.042 rows=77 loops=556)
Index Cond: (proc_ins_id = P.id)
-> Bitmap Index Scan on PROC_INS_HANDLERS_HANDLER_ID (cost=0.00..436.31 rows=29851 width=0) (actual time=9.495..9.495 rows=31125 loops=556)
Index Cond: (handler_id = '8feae683-f741-45de-b430-7db24b4f7660'::bpcharbyte)
-> Index Scan using eeeeeeeeeeeee_PKEY on eeeeeeeeeeeee C (cost=0.14..0.50 rows=1 width=81) (actual time=0.007..0.007 rows=1 loops=139)
Index Cond: (id = P.cate_id)
SubPlan 1
-> Index Scan using wf_act_instances_PKEY on wf_act_instances (cost=0.43..8.45 rows=1 width=14) (actual time=0.014..0.014 rows=1 loops=139)
Index Cond: (id = H.act_ins_id)
Planning Time: 1.753 ms
Execution Time: 2024.430 ms
AAAAAA 表是个视图,定义如下:
-----------------+--------------------------------+----------+--------+------+----------+------
case_id | character(36 byte) | | | | extended |
cate_id | character(36 byte) | | | | extended |
CATE_NAME | character varying(100 char) | | | | extended |
VIEW_URL | character varying(1024 char) | | | | extended |
PROC_INS_ID | character(36 byte) | | | | extended |
create_user_id | character(36 byte) | | | | extended |
current_user_id | character(36 byte) | | | | extended |
title | character varying(600 char) | | | | extended |
EMERGENCY | character(1 byte) | | | | extended |
dept_id | character(36 byte) | | | | extended |
handler_id | character(36 byte) | | | | extended |
handle_date | timestamp(3) without time zone | | | | plain |
create_date | timestamp(3) without time zone | | | | plain |
end_date | timestamp(3) without time zone | | | | plain |
PROC_INS_STATE | character(1 byte) | | | | extended |
HINT | character varying(60 byte) | | | | extended | SELECT P.case_id,
P.cate_id,
C.name AS CATE_NAME,
C.url AS VIEW_URL,
P.id AS PROC_INS_ID,
P.create_user_id,
P.current_user_id,
P.title,
P.emer_level AS EMERGENCY,
H.dept_id,
H.handler_id,
H.handle_date,
P.create_date,
P.end_date,
P.state AS PROC_INS_STATE,
( SELECT wf_act_instances.hint
FROM wf_act_instances
WHERE wf_act_instances.id = H.act_ins_id) AS HINT
FROM ccccccccccc H,
ddddddddddddd P,
eeeeeeeeeeeee C
WHERE H.proc_ins_id = P.id AND H.state = 'A'::bpchar::bpcharbyte AND H.category = 'H'::bpchar::bpcharbyte AND C.id = P.cate_id;
可以看到,两条SQL是除了LIKE模糊查询的过滤条件不一样,其他的写法是完全一致,
where title like '%通报%' 执行时间需要205ms,返回数据 1750 行,
where title like '%表扬%' 执行时间需要2024ms,返回数据 139 行,
正常情况下应该是谓词过滤条件为 '%表扬%' 的SQL语句执行速度更快才是,毕竟返回的数据更少,事实上这个过滤条件比前者慢了10倍。
前者执行计划:

后者执行计划:

通过对比发现后者SQL语句的表关联条件 proc_ins_id = P.id 竟然又 Recheck Cond 一次(回表),而前者的表关联条件是没有进行回表的 Hash Cond: (H.proc_ins_id = P.id),确定找到慢的地方。
增加联合索引优化:
create index idx_ccccccccccc_1_2 on ccccccccccc(proc_ins_id,handler_id);
优化后执行SQL语句:
优化后执行SQL语句: EXPLAIN ANALYZE
SELECT case_id,
cate_id,
cate_name,
view_url,
proc_ins_id,
create_user_id,
current_user_id,
title,
emergency,
dept_id,
handler_id,
handle_date,
create_date,
end_date,
proc_ins_state,
hint
FROM AAAAAA H
WHERE handler_id = '8feae683-f741-45de-b430-7db24b4f7660'
AND title like '%表扬%'
ORDER BY handle_date desc nulls last, emergency DESC
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=12129.97..12129.97 rows=3 width=464) (actual time=159.627..162.448 rows=139 loops=1)
Sort Key: H.handle_date DESC NULLS LAST, P.emer_level DESC
Sort Method: quicksort Memory: 97kB
-> Gather (cost=1000.58..12129.94 rows=3 width=464) (actual time=1.069..162.167 rows=139 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Nested Loop (cost=0.58..11104.29 rows=1 width=453) (actual time=1.615..148.219 rows=46 loops=3)
-> Nested Loop (cost=0.43..11103.79 rows=1 width=409) (actual time=1.585..148.059 rows=46 loops=3)
-> Parallel Seq Scan on ddddddddddddd P (cost=0.00..10934.44 rows=20 width=290) (actual time=1.197..145.137 rows=185 loops=3)
Filter: ((title)::text ~~ '%表扬%'::text)
Rows Removed by Filter: 164131
-> Index Scan using idx_ccccccccccc_1_2 on ccccccccccc H (cost=0.43..8.46 rows=1 width=156) (actual time=0.015..0.015 rows=0 loops=556)
Index Cond: ((proc_ins_id = P.id) AND (handler_id = '8feae683-f741-45de-b430-7db24b4f7660'::bpcharbyte))
Filter: ((state = 'A'::bpcharbyte) AND (category = 'H'::bpcharbyte))
-> Index Scan using eeeeeeeeeeeee_PKEY on eeeeeeeeeeeee C (cost=0.14..0.50 rows=1 width=81) (actual time=0.003..0.003 rows=1 loops=139)
Index Cond: (id = P.cate_id)
SubPlan 1
-> Index Scan using wf_act_instances_PKEY on wf_act_instances (cost=0.43..8.45 rows=1 width=14) (actual time=0.013..0.013 rows=1 loops=139)
Index Cond: (id = H.act_ins_id)
Planning Time: 1.443 ms
Execution Time: 162.906 ms
(21 行记录) EXPLAIN ANALYZE
SELECT case_id,
cate_id,
cate_name,
view_url,
proc_ins_id,
create_user_id,
current_user_id,
title,
emergency,
dept_id,
handler_id,
handle_date,
create_date,
end_date,
proc_ins_state,
hint
FROM AAAAAA H
WHERE handler_id = '8feae683-f741-45de-b430-7db24b4f7660'
AND title like '%通报%'
ORDER BY handle_date desc nulls last, emergency DESC; QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=16733.04..16733.23 rows=73 width=464) (actual time=246.592..252.130 rows=1750 loops=1)
Sort Key: H.handle_date DESC NULLS LAST, P.emer_level DESC
Sort Method: quicksort Memory: 968kB
-> Gather (cost=1000.58..16730.78 rows=73 width=464) (actual time=0.596..250.878 rows=1750 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Nested Loop (cost=0.58..15106.63 rows=30 width=453) (actual time=0.435..228.229 rows=583 loops=3)
-> Nested Loop (cost=0.43..15101.36 rows=30 width=409) (actual time=0.403..224.391 rows=583 loops=3)
-> Parallel Seq Scan on ddddddddddddd P (cost=0.00..10934.44 rows=499 width=290) (actual time=0.062..135.724 rows=4266 loops=3)
Filter: ((title)::text ~~ '%通报%'::text)
Rows Removed by Filter: 160050
-> Index Scan using idx_ccccccccccc_1_2 on ccccccccccc H (cost=0.43..8.34 rows=1 width=156) (actual time=0.021..0.021 rows=0 loops=12797)
Index Cond: ((proc_ins_id = P.id) AND (handler_id = '8feae683-f741-45de-b430-7db24b4f7660'::bpcharbyte))
Filter: ((state = 'A'::bpcharbyte) AND (category = 'H'::bpcharbyte))
-> Index Scan using eeeeeeeeeeeee_PKEY on eeeeeeeeeeeee C (cost=0.14..0.18 rows=1 width=81) (actual time=0.006..0.006 rows=1 loops=1750)
Index Cond: (id = P.cate_id)
SubPlan 1
-> Index Scan using wf_act_instances_PKEY on wf_act_instances (cost=0.43..8.45 rows=1 width=14) (actual time=0.015..0.015 rows=0 loops=1750)
Index Cond: (id = H.act_ins_id)
Planning Time: 1.551 ms
Execution Time: 252.611 ms
(21 行记录)
可以看到,两个谓词过滤条件不同的SQL语句执行时间已经相差无几,在正式环境上创建索引后SQL运行速度有明显提升,本案例已经优化完毕。

kingbase sql 回表优化案例的更多相关文章
- (转)减少oracle sql回表次数 提高SQL查询性能
要写出高效的SQL,那么必须必须得清楚SQL执行路径,介绍如何提高SQL性能的文章很多,这里不再赘述,本人来谈谈如何从 减少SQL回表次数 来提高查询性能,因为回表将导致扫描更多的数据块. 我们大家都 ...
- MySQL的索引单表优化案例分析
建表 建立本次优化案例中所需的数据库及数据表 CREATE DATABASE db0206; USE db0206; CREATE TABLE `db0206`.`article`( `id` INT ...
- mysql:如何利用覆盖索引避免回表优化查询
说到覆盖索引之前,先要了解它的数据结构:B+树. 先建个表演示(为了简单,id按顺序建): id name 1 aa 3 kl 5 op 8 aa 10 kk 11 kl 14 jk 16 ml 17 ...
- MySQL索引优化(索引单表优化案例)
1.单表查询优化 建表SQL CREATE TABLE IF NOT EXISTS `article` ( `id` INT(10) UNSIGNED NOT NULL PRIMARY KEY AUT ...
- MySQL索引优化(索引两表优化案例)
建表SQL CREATE TABLE IF NOT EXISTS `class` ( `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, `card` INT ...
- SQL Server表分区案例
--学习创建表分区脚本/*SQL SERVER 2005中以上版本,终于引入了表分区,就是说,当一个表里的数据很多时,可以将其分拆到多个的表里,大大提高了性能.下面举例子说明之*/ --------- ...
- Oracle学习(四)SQL高级--表优化相关(序列、视图等)
INDEX(索引) 可以在表中创建索引,以便更加快速高效地查询数据. 用户无法看到索引,它们只能被用来加速搜索/查询. PS:更新一个包含索引的表需要比更新一个没有索引的表花费更多的时间,这是由于索引 ...
- SQL多表查询案例
表结构: emp表: dept表: salgrade表: (1)查出至少有一个员工的部门.显示部门编号.部门名称.部门位置.部门人数. SELECT z.*,d.dname,d.loc FROM de ...
- SQL单表查询案例
表(emp)结构 (1)查询部门编号为10中所有经理,部门编号为20中所有销售员,还有即不是经理又不是销售员但其工资大或等于20000的所有员工详细资料. SELECT * FROM emp ; (2 ...
- MySQL优化:如何避免回表查询?什么是索引覆盖? (转)
数据库表结构: create table user ( id int primary key, name varchar(20), sex varchar(5), index(name) )engin ...
随机推荐
- 修改docker容器端口映射
原文地址 操作步骤如下 关闭docker systemctl stop dokcer 修改配置文件 位置一般是: /var/lib/docker/containers/containerId/host ...
- ESP32连接云服务器【WebSocket】
ESP32连接云服务器[ESP32+宝塔面板] 相关文章 ESP32连接MQ Sensor实现气味反应 https://blog.csdn.net/ws15168689087/article/deta ...
- NodeJS:安装CNPM
安装命令 npm install -g cnpm --registry=https://registry.npm.taobao.org 使用命令 cnpm install [name] 参考连接 ht ...
- SQL Server 内存占用较高 - 清除缓存 或 设置内存最大占用值
SQL Server对服务器内存的使用策略是用多少内存就占用多少内存,只用在服务器内存不足时,才会释放一点占用的内存,所以SQL Server 服务器内存往往会占用很高 查看内存状态: DBCC Me ...
- 基于consul实现docker跨主机网络通信
前言 IP: 192.168.0.10 192.168.0.11 系统版本:ubuntu 20.04 consul版本:1.11.1 官网下载地址: https://www.consul.io/dow ...
- 终于搞懂了python2和python3的encode(编码)与decode(解码)
终于搞懂了python2的编码 在python2下碰到非常多次的中文乱码,这次来梳理一下编码问题. 在python 2中默认编码是 ASCII,而在python 3中默认编码是 unicode. un ...
- 让C#调用vue组件里的方法
前言:web页面开发时采用的是vue开发的,后台语言是C# 需求:后台需要通过浏览器调用vue组件的方法 c# 可以调用xxx.html 中的script引用的js中定义的方法是可以调用的, 之前c# ...
- 8、Spring之基于注解的自动装配
8.1.场景模拟 8.1.1.UserDao接口及实现类 package org.rain.spring.dao; /** * @author liaojy * @date 2023/8/5 - 18 ...
- P3874 砍树 题解
前置 树形 dp,二分. 题意 本质上是一个树上背包,需要选不少于 \(k\) 个物品,每个物品有一个重量 \(w\) 和价值 \(v\),求性价比最大值. 分析 既然是性价比,显然是分数规划. 先介 ...
- [ABC128E] Roadwork
2023-01-14 题目 题目传送门 翻译 翻译 难度&重要性(1~10):4 题目来源 AtCoder 题目算法 区间覆盖,线段树,双堆 解题思路 可以将问题转化为区间覆盖问题和单点查询问 ...