一个分页排序SQL查询结果集不确定的案例
mhr18 2024-10-11 12:43 25 浏览 0 评论
前几天一位运价的兄弟提出一个关于分页排序SQL的问题,比较有意思,这里分享一下。
前些日子碰巧看了杨长老这篇文章:《让SQL成为一种生活方式:认识分页查询》,以下为原文摘要:
Oracle的分页查询语句有两种基本格式。第一种格式如下:
select * from
(
select a.*, rownum rn
from (select * from table_name) a
where rownum <= 30
)
where rn>=21;
上面给出的这个分页查询语句,在大多数情况拥有较高的效率。其中最内层的查询SELECT * FROM TABLE_NAME表示不进行翻页的原始查询语句。ROWNUM<= 40和RN >= 21控制分页查询的每页的范围。
第二种方式是去掉查询第二层的WHERE ROWNUM <= 30语句,在查询的最外层控制分页的最小值和最大值。语法如下: “`
select * from
(
select a.*, rownum rn
from (select * from table_name) a
)
where rn between 21 and 30;
对比这两种写法,绝大多数的情况下,第一个查询的效率比第二个高得多。这是由于CBO优化模式下,Oracle可以将外层的查询条件推到内层查询中,以提高内层查询的执行效率。
对于第一个查询语句,第二层的查询条件WHERE ROWNUM <=
30就可以被Oracle推入到内层查询中,这样Oracle查询的结果一旦超过了ROWNUM限制条件,就终止查询将结果返回了。而第二个查询语句,由于查询条件BETWEEN 21 AND 30是存在于查询的第三层,而Oracle无法将第三层的查询条件推到最内层(即使推到最内层也没有意义,因为最内层查询不知道RN代表什么)。因此,对于第二个查询语句,Oracle最内层返回给中间层的是所有满足条件的数据,而中间层返回给最外层的也是所有数据。数据的过滤在最外层完成,显然这个效率要比第一个查询低得多。
同事提出的这条SQL,正是使用了上面提到的第一种写法。以下是叙述的信息,其中SQL做了脱敏,不影响原义。
第一条SQL是不带分页的查询语句,结果集中有一条CLS_CODE是B。
(此处原文有一些限定条件,确保第一条SQL的结果集肯定包含第二条和第三条的结果集,即CLS_CODE=B应该只有一条记录在第二条或第三条SQL的结果集中。)
SELECT T.C_CODE, (CASE T.FLG WHEN 'C' THEN 0 WHEN 'A' THEN 1 END) AS FLG FROM TABLE T LEFT JOIN RULE R ON TRIM(R.CODE) = 'PUB' AND R.NO = T.FILE_NO AND R._REC_NO = T.NO WHERE T.CODE = 'CA' AND T.D_DATE >= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.FIRST_DATE >= to_Date('2016-08-10 00:00:00','yyyy-mm-dd hh24:mi:ss') AND T.FIRST_DATE <= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.LAST_DATE >= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.EFF_DATE <= T.D_DATE AND T.FIRST_DATE <= T.LAST_DATE;
第二条SQL是带分页的查询语句(5000条一页的第一页),查询结果不包含CLS_CODE是B的数据。
select * from ( select tmp_page.*, rownum row_id from (SELECT T.C_CODE, (CASE T.FLG WHEN 'C' THEN 0 WHEN 'A' THEN 1 END) AS FLG FROM TABLE T LEFT JOIN RULE R ON TRIM(R.CODE) = 'PUB' AND R.NO = T.FILE_NO AND R._REC_NO = T.NO WHERE T.CODE = 'CA' AND T.D_DATE >= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.FIRST_DATE >= to_Date('2016-08-10 00:00:00','yyyy-mm-dd hh24:mi:ss') AND T.FIRST_DATE <= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.LAST_DATE >= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.EFF_DATE <= T.D_DATE AND T.FIRST_DATE <= T.LAST_DATE ORDER BY T.CODE, T.O_STN, T.D_STN, T.FIRST_DATE, T.EFF_DATE ) tmp_page where rownum <= 5000) x WHERE x.row_id > 0;
第三条SQL是带分页的查询语句(5000条一页的第二页),查询结果不包含CLS_CODE是B的数据。
select * from ( select tmp_page.*, rownum row_id from (SELECT T.C_CODE, (CASE T.FLG WHEN 'C' THEN 0 WHEN 'A' THEN 1 END) AS FLG FROM TABLE T LEFT JOIN RULE R ON TRIM(R.CODE) = 'PUB' AND R.NO = T.FILE_NO AND R._REC_NO = T.NO WHERE T.CODE = 'CA' AND T.D_DATE >= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.FIRST_DATE >= to_Date('2016-08-10 00:00:00','yyyy-mm-dd hh24:mi:ss') AND T.FIRST_DATE <= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.LAST_DATE >= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.EFF_DATE <= T.D_DATE AND T.FIRST_DATE <= T.LAST_DATE ORDER BY T.CODE, T.O_STN, T.D_STN, T.FIRST_DATE, T.EFF_DATE ) tmp_page where rownum <= 10000) x WHERE x.row_id > 5000;
第二次执行查询第二条和第三条SQL,两个结果又都包含CLS_CODE是B的数据,但实际应该只出现在一个查询结果中。
如果第二条和第三条SQL的order by中加过一次C_CODE之后,再怎么查都有B,即使将排序中加上的C_CODE去掉,SQL恢复到初始状态,也还是都有B,而且第一第二页都有B。
还有一些辅助的信息:
1.SQL执行过程中,没有数据变更。
2.TABLE表是普通堆表,其中
主键:NO, FILE_NO, CODE
唯一约束:RULE_ID
外键:FILE_NO, FRO,关联第三张表
索引:O_STN, D_STN, EFF_DATE, D_DATE
首先,这条分页SQL采用的是上面杨长老介绍的第一种写法,语法上正确。
其次,第一次执行第一条和第二条SQL,结果集没有C_CODE=B的记录,但实际应该至少有一个结果集中包含这条记录。
第三,第二次执行第一条和第二条SQL,两个结果集又都包含C_CODE=B的记录,但实际只应该有一个结果集包含这条记录。
最后,增加order by的C_CODE字段,无论是否再删除,第二条和第三条SQL结果集是都包含C_CODE=B的记录。
总结起来,就是C_CODE=B的记录在第一页和第二页出现的几率是随机的,并无明显的规律。
语法没错,但结果集的语义好像出现了问题,原因是什么?
原因就出在了ROWNUM的使用上。
TOM曾经写了一篇文章《On ROWNUM and Limiting Results》,非常清晰地介绍了ROWNUM的使用,值得我们反复阅读和学习。
ROWNUM是一个查询中可以使用的伪列,之所以叫伪列,是因为表中记录根本没有这个列信息。ROWNUM的取值从1,2,3一直到N,N是查询结果集的总数。ROWNUM并不会永久地赋予某一行,所以想要直接查询第五行数据是不可能的,因为表中根本没有这个数据。
ROWNUM是在他传向查询的谓词阶段之后被赋予结果集的某行记录上,而且这之后才会继续执行排序或聚集等操作,例如如下SQL
select ..., ROWNUM from t where <where clause> group by <columns> having <having clause> order by <columns>;
他的执行顺序是,
1.FROM/WHERE子句。
2.ROWNUM会被赋予FROM/WHERE子句输出结果的每一行,并且可以开始递增。
3.SELECT子句。
4.GROUP BY子句。
5.HAVING子句。
6.ORDER BY子句。
为了便于说明,我们将上面的SQL简化为,
select * from (select tmp_page.*, rownum row_id from (select t.c_code, ... from table t where ... order by t.code, t.o_stn, t.d_stn, t.first_date, t.eff_date) k where rownum <= 5000) xwhere x.rownum > 0;
按照上面的执行顺序,
1.执行from table t where …
2.执行where rownum <= 5000
3.执行select t.c_code, …
4.执行order by t.code, t.o_stn, t.d_stn, t.first_date, t.eff_date
前三步会得到一个5000行的结果集,第四步会对这个结果集按照t.code, t.o_stn, t.d_stn, t.first_date, t.eff_date这些字段依次做排序了,我们再结合这张表的属性,order by的这些字段没有一个能保证值唯一,换句话说,这几个字段值相同的记录可能是有重复的(实际确实是),在这种情况下,查询结果集的顺序是不确定的,无法保证顺序。
我们借用Tom的一个实验来直观看下这种说法,首先创建测试表,id列是重复性较高的整型值,data列是1-100的随机数,
我们先查询其中的1001-1010行,
再查询1001-1011行,
order by的列id重复值较多,从两次查询结果集中可以看出,对应的所有记录ID值都是重复的0,1001-1010和1001-1011记录的行数正确,但对应的DATA值是不同的,1001-1010的第1001条记录是27,1001-1011的第1001条记录是47。这就可以证明order by字段有重复值的情况下,查询结果集的顺序是不确定的,进而我们可以推测,order by字段值的重复度和结果集不确定性的程度有关,如果order by字段值没有重复的,则结果集就是确定的。这就可以说明为什么最开始的分页SQL两次查询的结果集中,C_CODE=B的记录出现是不确定的。
再看Tom所说,
One important thing about using this pagination query is that the ORDER BY statement should order by something unique. If what you are ordering by is not unique, you should add something to the end of the ORDER BY to make it so. The rows will have a definite, deterministic order and the pagination query will deterministically return the rows as expected.
解决方案就是向order by中增加一些确保唯一的字段。这里我们选择增加rowid,
可以看出,两次查询的结果集中,相同行数的data字段值是相同的,即已经是确定的结果集了。
针对上面的问题SQL,实际采用的是唯一约束RULE_ID字段,新的SQL如下,
select * from ( select tmp_page.*, rownum row_id from (SELECT T.C_CODE, (CASE T.FLG WHEN 'C' THEN 0 WHEN 'A' THEN 1 END) AS FLG FROM TABLE T LEFT JOIN RULE R ON TRIM(R.CODE) = 'PUB' AND R.NO = T.FILE_NO AND R._REC_NO = T.NO WHERE T.CODE = 'CA' AND T.D_DATE >= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.FIRST_DATE >= to_Date('2016-08-10 00:00:00','yyyy-mm-dd hh24:mi:ss') AND T.FIRST_DATE <= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.LAST_DATE >= to_Date('2016-08-10 23:59:59','yyyy-mm-dd hh24:mi:ss') AND T.EFF_DATE <= T.D_DATE AND T.FIRST_DATE <= T.LAST_DATE ORDER BY T.CODE, T.O_STN, T.D_STN, T.FIRST_DATE, T.EFF_DATE, T.RULE_ID ) tmp_page where rownum <= 5000) x WHERE x.row_id > 0;
无论是查询1-5000,还是5001-10000,结果都是正确的,不再是不确定的结果集了。
总结:
使用ROWNUM做分页时,order by需要有可以唯一确定记录的字段,否则查询结果集就是不确定的,使用唯一索引字段、唯一约束字段或rowid均可。当然这没有探究SQL执行效率问题,如果涉及这部分内容,还需要具体根据实际情况来考虑字段的选择。
相关推荐
- 订单超时自动取消业务的 N 种实现方案,从原理到落地全解析
-
在分布式系统架构中,订单超时自动取消机制是保障业务一致性的关键组件。某电商平台曾因超时处理机制缺陷导致日均3000+订单库存锁定异常,直接损失超50万元/天。本文将从技术原理、实现细节、...
- 使用Spring Boot 3开发时,如何选择合适的分布式技术?
-
作为互联网大厂的后端开发人员,当你满怀期待地用上SpringBoot3,准备在项目中大显身手时,却发现一个棘手的问题摆在面前:面对众多分布式技术,究竟该如何选择,才能让SpringBoot...
- 数据库内存爆满怎么办?99%的程序员都踩过这个坑!
-
你的数据库是不是又双叒叕内存爆满了?!服务器监控一片红色警告,老板在群里@所有人,运维同事的电话打爆了手机...这种场景是不是特别熟悉?别慌!作为一个在数据库优化这条路上摸爬滚打了10年的老司机,今天...
- springboot利用Redisson 实现缓存与数据库双写不一致问题
-
使用了Redisson来操作Redis分布式锁,主要功能是从缓存和数据库中获取商品信息,以下是针对并发时更新缓存和数据库带来不一致问题的解决方案1.基于读写锁和删除缓存策略在并发更新场景下,...
- 外贸独立站数据库炸了?对象缓存让你起死回生
-
上周黑五,一个客户眼睁睁看着服务器CPU飙到100%——每次页面加载要查87次数据库。这让我想起2024年Pantheon的测试:Redis缓存能把WooCommerce查询速度提升20倍。跨境电商最...
- 手把手教你在 Spring Boot3 里纯编码实现自定义分布式锁
-
为什么要自己实现分布式锁?你是不是早就受够了引入各种第三方依赖时的繁琐?尤其是分布式锁这块,每次集成Redisson或者Zookeeper,都得额外维护一堆配置,有时候还会因为版本兼容问题头疼半...
- 如何设计一个支持百万级实时数据推送的WebSocket集群架构?
-
面试解答:要设计一个支持百万级实时数据推送的WebSocket集群架构,需从**连接管理、负载均衡、水平扩展、容灾恢复**四个维度切入:连接层设计-**长连接优化**:采用Netty或Und...
- Redis数据结构总结——面试最常问到的知识点
-
Redis作为主流的nosql存储,面试时经常会问到。其主要场景是用作缓存,分布式锁,分布式session,消息队列,发布订阅等等。其存储结构主要有String,List,Set,Hash,Sort...
- skynet服务的缺陷 lua死循环
-
服务端高级架构—云风的skynet这边有一个关于云风skynet的视频推荐给大家观看点击就可以观看了!skynet是一套多人在线游戏的轻量级服务端框架,使用C+Lua开发。skynet的显著优点是,...
- 七年Java开发的一路辛酸史:分享面试京东、阿里、美团后的心得
-
前言我觉得有一个能够找一份大厂的offer的想法,这是很正常的,这并不是我们的饭后谈资而是每个技术人的追求。像阿里、腾讯、美团、字节跳动、京东等等的技术氛围与技术规范度还是要明显优于一些创业型公司...
- mysql mogodb es redis数据库之间的区别
-
1.MySQL应用场景概念:关系型数据库,基于关系模型,使用表和行存储数据。优点:支持ACID事务,数据具有很高的一致性和完整性。缺点:垂直扩展能力有限,需要分库分表等方式扩展。对于复杂的查询和大量的...
- redis,memcached,nginx网络组件
-
1.理解阻塞io,非阻塞io,同步io,异步io的区别2.理解BIO和AIO的区别io多路复用只负责io检测,不负责io操作阻塞io中的write,能写多少是多少,只要写成功就返回,譬如准备写500字...
- SpringBoot+Vue+Redis实现验证码功能
-
一个小时只允许发三次验证码。一次验证码有效期二分钟。SpringBoot整合Redis...
- AWS MemoryDB 可观测最佳实践
-
AWSMemoryDB介绍AmazonMemoryDB是一种完全托管的、内存中数据存储服务,专为需要极低延迟和高吞吐量的应用程序而设计。它与Redis和Memcached相似,但具有更...
- 从0构建大型AI推荐系统:实时化引擎从工具到生态的演进
-
在AI浪潮席卷各行各业的今天,推荐系统正从幕后走向前台,成为用户体验的核心驱动力。本文将带你深入探索一个大型AI推荐系统从零起步的全过程,揭示实时化引擎如何从单一工具演进为复杂生态的关键路径。无论你是...
你 发表评论:
欢迎- 一周热门
-
-
Redis客户端 Jedis 与 Lettuce
-
高并发架构系列:Redis并发竞争key的解决方案详解
-
redis如何防止并发(redis如何防止高并发)
-
Java SE Development Kit 8u441下载地址【windows版本】
-
开源推荐:如何实现的一个高性能 Redis 服务器
-
redis安装与调优部署文档(WinServer)
-
Redis 入门 - 安装最全讲解(Windows、Linux、Docker)
-
一文带你了解 Redis 的发布与订阅的底层原理
-
Redis如何应对并发访问(redis控制并发量)
-
Oracle如何创建用户,表空间(oracle19c创建表空间用户)
-
- 最近发表
- 标签列表
-
- oracle位图索引 (74)
- oracle批量插入数据 (65)
- oracle事务隔离级别 (59)
- oracle主从同步 (56)
- oracle 乐观锁 (53)
- redis 命令 (83)
- php redis (97)
- redis 存储 (67)
- redis 锁 (74)
- 启动 redis (73)
- redis 时间 (60)
- redis 删除 (69)
- redis内存 (64)
- redis并发 (53)
- redis 主从 (71)
- redis同步 (53)
- redis结构 (53)
- redis 订阅 (54)
- redis 登录 (62)
- redis 面试 (58)
- redis问题 (54)
- 阿里 redis (67)
- redis的缓存 (57)
- lua redis (59)
- redis 连接池 (64)