PostgreSQL、KingBase 数据库 ORDER BY LIMIT 查询缓慢案例
好久没写博客了，最近从人大金仓离职了，新公司入职了蚂蚁集团，正在全力学习 OcenaBase 数据库的体系结构中。
以后分享的案例知识基本上都是以 OcenaBase 分布式数据库为主了，呦西。
昨天帮朋友看了个金仓 KES数据库的 SQL 案例，废话不说，直接贴SQL：
慢SQL（执行时间 8s ，限制返回 30 行）
explain analyze
SELECT GI.ID,
GI.MODULE_ID,
GI.BT,
GI.WH,
GI.JJCD_TEXT,
GI.CREATE_DEPTNAME,
GI.CREATE_TIME,
GI.MODULE_NAME
FROM gifgifgif GI
INNER JOIN gufgufguf GUF ON (GUF.ifid = GI.ID)
WHERE GI.ROWSTATE > - 1
AND (GUF.usid = '0' OR GUF.usid = '210317100256if6gVcTb3Ado1o2ytLs')
AND ((GI.BT LIKE '%签%') OR (GI.MODULE_NAME LIKE '%签%') OR (GI.WH LIKE '%签%') OR (GI.JJCD_TEXT LIKE '%签%') OR
(GI.CREATE_DEPTNAME LIKE '%签%'))
ORDER BY GI.CREATE_TIME DESC LIMIT 30;
慢SQL执行计划
QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------
Limit (cost=1001.05..17578.06 rows=30 width=240) (actual time=6458.263..8763.733 rows=7 loops=1)
-> Gather Merge (cost=1001.05..3879467.79 rows=7019 width=240) (actual time=6458.261..8763.728 rows=7 loops=1)
Workers Planned: 4
Workers Launched: 4
-> Nested Loop (cost=0.99..3877631.71 rows=1755 width=240) (actual time=2843.144..8274.217 rows=1 loops=5)
-> Parallel Index Scan Backward using gifgifgif_CREATE_TIME1 on gifgifgif GI (cost=0.43..1158925.09 rows=433728 width=240) (actual time=0.043..2159.037 rows=350466 loops=5)
Filter: ((ROWSTATE > '-1'::numeric) AND (((BT)::text ~~ '%签%'::text) OR ((MODULE_NAME)::text ~~ '%签%'::text) OR ((WH)::text ~~ '%签%'::text) OR ((JJCD_TEXT)::text ~~ '%签%'::text) OR ((CREATE_DEPTNAME)::text ~~ '%
%'::text)))
Rows Removed by Filter: 423271
-> Index Only Scan using idx_gufgufguf_1_2_3 on gufgufguf GUF (cost=0.56..6.26 rows=1 width=32) (actual time=0.017..0.017 rows=0 loops=1752329) -- 慢：(1752329/5) * 0.017 / 1000 = 5.95s
Index Cond: (ifid = (GI.ID)::text)
Filter: (((usid)::text = '0'::text) OR ((usid)::text = '210317100256if6gVcTb3Ado1o2ytLs'::text))
Rows Removed by Filter: 3
Heap Fetches: 0
Planning Time: 0.832 ms
Execution Time: 8763.803 ms
(15 行记录)
我看到这计划简直无语，这种SQL不能 300 ms出来就绝对有问题，而且这么简单的语句都能用上并行，真的服了。
Index Only Scan using idx_gufgufguf_1_2_3 on gufgufguf GUF 每个并行进程执行 5.95s 这也太拉跨了。
看执行计划基本都是用 Index Scan 或者是 Index Only Scan，但是本SQL 谓词过滤条件很多 or ，其实优化器如果执行位图扫描才是最优解计划，但是CBO偏偏没执行！！！
SQL去掉 LIMIT 30限制条件:
explain analyze
SELECT GI.ID,
GI.MODULE_ID,
GI.BT,
GI.WH,
GI.JJCD_TEXT,
GI.CREATE_DEPTNAME,
GI.CREATE_TIME,
GI.MODULE_NAME
FROM gifgifgif GI
INNER JOIN gufgufguf GUF ON (GUF.ifid = GI.ID)
WHERE GI.ROWSTATE > - 1
AND (GUF.usid = '0' OR GUF.usid = '210317100256if6gVcTb3Ado1o2ytLs')
AND ((GI.BT LIKE '%签%') OR (GI.MODULE_NAME LIKE '%签%') OR (GI.WH LIKE '%签%') OR (GI.JJCD_TEXT LIKE '%签%') OR
(GI.CREATE_DEPTNAME LIKE '%签%'))
ORDER BY GI.CREATE_TIME DESC ;
去掉 LIMIT 30限制条件SQL执行计划：
QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------
Gather Merge (cost=98222.89..99026.61 rows=6792 width=240) (actual time=33.640..35.974 rows=7 loops=1)
Workers Planned: 3
Workers Launched: 3
-> Sort (cost=97222.85..97228.51 rows=2264 width=240) (actual time=26.724..26.725 rows=2 loops=4)
Sort Key: GI.CREATE_TIME DESC
Sort Method: quicksort Memory: 25kB
Worker 0: Sort Method: quicksort Memory: 25kB
Worker 1: Sort Method: quicksort Memory: 25kB
Worker 2: Sort Method: quicksort Memory: 26kB
-> Nested Loop (cost=510.90..97096.70 rows=2264 width=240) (actual time=11.118..26.693 rows=2 loops=4)
-> Parallel Bitmap Heap Scan on gufgufguf GUF (cost=510.35..59045.81 rows=5049 width=32) (actual time=0.480..3.498 rows=1178 loops=4)
Recheck Cond: (((usid)::text = '0'::text) OR ((usid)::text = '210317100256if6gVcTb3Ado1o2ytLs'::text))
Heap Blocks: exact=1464
-> BitmapOr (cost=510.35..510.35 rows=15652 width=0) (actual time=1.567..1.568 rows=0 loops=1)
-> Bitmap Index Scan on gufgufguf_usid (cost=0.00..251.26 rows=7826 width=0) (actual time=0.022..0.022 rows=0 loops=1)
Index Cond: ((usid)::text = '0'::text)
-> Bitmap Index Scan on gufgufguf_usid (cost=0.00..251.26 rows=7826 width=0) (actual time=1.545..1.545 rows=4713 loops=1)
Index Cond: ((usid)::text = '210317100256if6gVcTb3Ado1o2ytLs'::text)
-> Index Scan using gifgifgif_PKEY1 on gifgifgif GI (cost=0.56..7.54 rows=1 width=240) (actual time=0.019..0.019 rows=0 loops=4713)
Index Cond: ((ID)::text = (GUF.ifid)::text)
Filter: ((ROWSTATE > '-1'::numeric) AND (((BT)::text ~~ '%签%'::text) OR ((MODULE_NAME)::text ~~ '%签%'::text) OR ((WH)::text ~~ '%签%'::text) OR ((JJCD_TEXT)::text ~~ '%签%'::text) OR ((CREATE_DEPTNAME)::text ~~ '%
%'::text)))
Rows Removed by Filter: 1
Planning Time: 0.815 ms
Execution Time: 36.060 ms
(24 行记录)
可以看到去掉LIMIT 30 以后，CBO能正常使用上 Bitmap Index Scan + BitmapOr 的查询策略，SQL只需要 36ms就能跑出结果。
PG比较牛逼的地方是B+树索引能基于SQL的查询条件，自动能转换成位图索引的查询策略。
像这种情况就简单了，只需要改变下限制SQL返回条数的逻辑即可，kingbase也兼容Oracle rownum 的语法，我们可以将上面SQL等价改成 rownum来进行现在。
LIMIT 改写成 rownum ：
explain analyze
SELECT * FROM (
SELECT GI.ID,
GI.MODULE_ID,
GI.BT,
GI.WH,
GI.JJCD_TEXT,
GI.CREATE_DEPTNAME,
GI.CREATE_TIME,
GI.MODULE_NAME
FROM gifgifgif GI
INNER JOIN gufgufguf GUF ON (GUF.ifid = GI.ID)
WHERE GI.ROWSTATE > - 1
AND (GUF.usid = '0' OR GUF.usid = '210317100256if6gVcTb3Ado1o2ytLs')
AND ((GI.BT LIKE '%签%') OR (GI.MODULE_NAME LIKE '%签%') OR (GI.WH LIKE '%签%') OR (GI.JJCD_TEXT LIKE '%签%') OR
(GI.CREATE_DEPTNAME LIKE '%签%'))
ORDER BY GI.CREATE_TIME DESC) WHERE ROWNUM <= 30;
LIMIT 改写成 rownum 执行计划：
QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------
Count (cost=98222.89..99162.45 rows=0 width=240) (actual time=31.418..33.691 rows=7 loops=1)
Stop Keys: (ROWNUM <= 30)
-> Gather Merge (cost=98222.89..99026.61 rows=6792 width=240) (actual time=31.415..33.686 rows=7 loops=1)
Workers Planned: 3
Workers Launched: 3
-> Sort (cost=97222.85..97228.51 rows=2264 width=240) (actual time=26.497..26.498 rows=2 loops=4)
Sort Key: GI.CREATE_TIME DESC
Sort Method: quicksort Memory: 25kB
Worker 0: Sort Method: quicksort Memory: 25kB
Worker 1: Sort Method: quicksort Memory: 27kB
Worker 2: Sort Method: quicksort Memory: 25kB
-> Nested Loop (cost=510.90..97096.70 rows=2264 width=240) (actual time=14.246..26.465 rows=2 loops=4)
-> Parallel Bitmap Heap Scan on gufgufguf GUF (cost=510.35..59045.81 rows=5049 width=32) (actual time=0.513..3.401 rows=1178 loops=4)
Recheck Cond: (((usid)::text = '0'::text) OR ((usid)::text = '210317100256if6gVcTb3Ado1o2ytLs'::text))
Heap Blocks: exact=1373
-> BitmapOr (cost=510.35..510.35 rows=15652 width=0) (actual time=1.664..1.664 rows=0 loops=1)
-> Bitmap Index Scan on gufgufguf_usid (cost=0.00..251.26 rows=7826 width=0) (actual time=0.024..0.024 rows=0 loops=1)
Index Cond: ((usid)::text = '0'::text)
-> Bitmap Index Scan on gufgufguf_usid (cost=0.00..251.26 rows=7826 width=0) (actual time=1.639..1.639 rows=4713 loops=1)
Index Cond: ((usid)::text = '210317100256if6gVcTb3Ado1o2ytLs'::text)
-> Index Scan using gifgifgif_PKEY1 on gifgifgif GI (cost=0.56..7.54 rows=1 width=240) (actual time=0.019..0.019 rows=0 loops=4713)
Index Cond: ((ID)::text = (GUF.ifid)::text)
Filter: ((ROWSTATE > '-1'::numeric) AND (((BT)::text ~~ '%签%'::text) OR ((MODULE_NAME)::text ~~ '%签%'::text) OR ((WH)::text ~~ '%签%'::text) OR ((JJCD_TEXT)::text ~~ '%签%'::text) OR ((CREATE_DEPTNAME)::text
~~ '%签%'::text)))
Rows Removed by Filter: 1
Planning Time: 0.897 ms
Execution Time: 33.778 ms
(26 行记录)
可以看到SQL通过将LIMIT 改写成 rownum 以后，原来执行时间 8s 降低到 33ms 就能跑出结果了，本条SQL到此已经优化完毕。
最后问题：那为什么原SQL使用 limit 会慢？改成 rownum 后速度能秒出，通常情况下来说 limit 是PG提供原生的语法，性能应该更好才是？
解答：是因为在PostgreSQL中，LIMIT子句本身不直接与索引类型相关联，而是用于指定返回的记录数。然而，当LIMIT与ORDER BY结合使用时，PostgreSQL的查询优化器可能会利用B+树索引来加速查询。
这是因为B+树索引能够有效地支持有序数据的检索，使得数据库能够快速地定位到需要的记录而不必扫描整个表或索引。
然而需要通过索引进行排序的话，必然要通过 Index Scan 或者 Index Only Scan 扫描才可以对数据进行升序或者降序排序，而位图索引是不支持对数据进行排序功能的。
所以为什么一开始SQL会使用 Index Scan 和 Index Only Scan 而不使用 Bitmap Index Scan + BitmapOr 的查询策略。
各位读者以后在kingbase数据库进行业务开发，如果需要谓词过滤条件中有 or 排序限制条件中有 order by + limit 的需求，尽量对业务SQL进行评估，从而选择使用 rownum 还是 limit 语句来进行限制数据。
如果在postgresql 进行开发的话遇到这种需求（pg不支持rownum写法），还需要在外面再包一层查询，使用 row_number() over() 窗口函数来进行限制。
PostgreSQL、KingBase 数据库 ORDER BY LIMIT 查询缓慢案例的更多相关文章
- Oracle数据库order by排序查询分页比不分页还慢问题解决办法
简单说下问题,有一个JDBC的查询SQL,分页查询语句中有一个排序order by create_time,理论上来说JDBC查询已经是比较底层的技术了,没有像Hibernate.MyBatis那样又 ...
- 第二百八十八节，MySQL数据库-索引、limit分页、执行计划、慢日志查询
MySQL数据库-索引.limit分页.执行计划.慢日志查询 索引,是数据库中专门用于帮助用户快速查询数据的一种数据结构.类似于字典中的目录,查找字典内容时可以根据目录查找到数据的存放位置,然后直接获 ...
- MySql学习(二) —— where / having / group by / order by / limit 简单查询
注:该MySql系列博客仅为个人学习笔记. 这篇博客主要记录sql的五种子句查询语法! 一个重要的概念:将字段当做变量看,无论是条件,还是函数,或者查出来的字段. select五种子句 where 条 ...
- where / having / group by / order by / limit 简单查询
目录 1.基础查询 -- where 2. group by 与 统计函数 3. having 4.where + group by + having + 函数 综合查询 5. order by + ...
- .NET Core ORM 类库Petapoco中对分页Page添加Order By对查询的影响
最近一直在使用Petapoco+Entity Framework Core结合开发一套系统. 使用EFCore进行Code First编码,使用PMC命令生成数据库表的信息. 使用Petapoco进行 ...
- MySQL数据库之单双表查询
单表查询 先创建表 #创建表 create table employee( id int not null unique auto_increment, name varchar(20) not nu ...
- mysql数据库补充知识2 查询数据库记录信息之单表查询
一 单表查询的语法 SELECT 字段1,字段2... FROM 表名 WHERE 条件 GROUP BY field HAVING 筛选 ORDER BY field LIMIT 限制条数 二 关键 ...
- postgresql查看数据库占用的物理存储空间大小
1.手动查看: 查看数据库postgres的oid postgres=# SELECT oid from pg_database where datname='postgres'; oid------ ...
- MySQL数据库之单表查询中关键字的执行顺序
目录 MySQL数据库之单表查询中关键字的执行顺序 1 语法顺序 2 执行顺序 3 关键字使用语法 MySQL数据库之单表查询中关键字的执行顺序 1 语法顺序 select distinct from ...
- MySQL/MariaDB数据库的多表查询操作
MySQL/MariaDB数据库的多表查询操作 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.单表查询小试牛刀 [root@node105.yinzhengjie.org.cn ...
随机推荐
- axios发送请求时携带token
请求头携带token async getUserlist(){ // 需要授权的Api,必须在青丘头中使用Authorization 字段提供token令牌 const AUTH_TOKEN=loca ...
- Promise练习文件读取
1. fs读取文件 const fs=require('fs');//引入文件读取模块 fs.readFile('./README.md',(err,data)=>{ // 如果出现错误,抛出错 ...
- 【五】AI Studio 项目详解【VisualDL工具、环境使用说明、脚本任务、图形化任务、(五)在线部署及预测】PARL
相关文章 [一]-环境配置+python入门教学 [二]-Parl基础命令 [三]-Notebook.&pdb.ipdb 调试 [四]-强化学习入门简介 [五]-Sarsa&Qlear ...
- C/C++ x32 Inline Hook 代码封装
Hook 技术常被叫做挂钩技术,挂钩技术其实早在DOS时代就已经存在了,该技术是Windows系统用于替代DOS中断机制的具体实现,钩子的含义就是在程序还没有调用系统函数之前,钩子捕获调用消息并获得控 ...
- 提升编码幸福感的秘密「GitHub 热点速览」
写代码是一个充满挑战的事情,在这段充满挑战的旅途中,我们都渴望找到那个提升幸福感的秘密.没准是更先进或是更快的工具,希望本期热点速递的开源项目,能给你带来启迪和乐趣,上菜! 第一个上场的是一款用 Ru ...
- 1cm+1kg纤薄身材 带来14小时超长续航！华硕灵耀13 2023评测
一.前言:华硕推出1cm+1kg超轻薄笔记本 还有OLED好屏加持 随着处理器能效的不断进步,轻薄本已经不存在性能羸弱的问题了,也给了各大厂商极大的发挥空间,不过市面上的轻薄本厚度普遍在15~20mm ...
- 零基础入门学习Java课堂笔记 ——day04
Java数组 1.数组概述 定义:数组是相同类型的有序集合,同一组同一类型的数据可以按照先后次序排列组合在一起,其中一个数据可以称为元素,每个数组元素可以通过一个下表访问它们 2.数组声明创建 dat ...
- 阿里巴巴 ali1688 Date +0800的问题
package com.example.testredis.controller; import java.text.DateFormat; import java.text.ParseExcepti ...
- MySQL 将执行结果保存到文件
1. 使用mysql的tee命令记录对mysql的操作过程 (1)第一种情况是在连接数据库的时候使用tee >mysql -u root -p --tee=C:/log.txt ...
- Linux证书问题：curl#60 - “The certificate issuer‘s certificate has expired
问题说明 最近在centos7上打算安装php7版本,需要下载一个外网https的yum源,结果报错如下: 执行命令 rpm -Uvh https://mirror.webtatic.com/yum/ ...