有趣的rownum测试(r10笔记第49天)

rownum在平时的使用中总是一个很自然的语法。如果说这个rownum是否有规律,可能很多人都会模棱两可。到底是还是不是呢,我们来做几个测试来说明。 这个结果也是在一个测试过程中无意发现的,没想到还蛮有意思。 我们会开启两个会话,会话1,会话2 首先初始化数据: create table test_lock as select * from all_objects where rownum<100; 会话1: 运行下面的语句,根据rownum得到5行数据,到底是按照rowid还是按照数值的大小呢。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 20 AAAVmRAAEAAAAV7AAA 46 AAAVmRAAEAAAAV7AAB 28 AAAVmRAAEAAAAV7AAC 15 AAAVmRAAEAAAAV7AAD 29 AAAVmRAAEAAAAV7AAE 可以从这个输出来看,应该是按照rowid的方式来的。 当然还没有到下结论的时候,我们添加主键或者唯一性索引来看看是否会有变化 添加主键: SQL> alter table test_lock modify(object_id primary key); Table altered. 再次查看rownum的情况,就发生了变化。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 2 AAAVmRAAEAAAAV7AAw 3 AAAVmRAAEAAAAV7AAF 4 AAAVmRAAEAAAAV7AAx 5 AAAVmRAAEAAAAV7AAa 6 AAAVmRAAEAAAAV7AAV 通过以上的输出可以看出这个时候是按照主键列来排序的,数据是有序的。 这个时候我们可以分成两个场景来测试。一个是没有主键/唯一性索引,一个是存在主键/唯一性索引 先删除主键 SQL> alter table test_lock drop primary key; Table altered. 测试没有主键/唯一性索引的场景,还是按照rowid排列。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 20 AAAVmRAAEAAAAV7AAA 46 AAAVmRAAEAAAAV7AAB 28 AAAVmRAAEAAAAV7AAC 15 AAAVmRAAEAAAAV7AAD 29 AAAVmRAAEAAAAV7AAE 我们更新一条数据,object_id=20的记录。 SQL> update test_lock set object_id=1000123 where object_id=20; 1 row updated. rownum是否有其它的变化呢。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 1000123 AAAVmWAAEAAAEUbAAA 46 AAAVmWAAEAAAEUbAAB 28 AAAVmWAAEAAAEUbAAC 15 AAAVmWAAEAAAEUbAAD 29 AAAVmWAAEAAAEUbAAE 可以看出这个结果是显而易见的。 再更新一条记录。 SQL> update test_lock set object_id=10001223 where object_id=46; 1 row updated. 查看rownum的情况, SQL> update test_lock set object_id=10001223 where object_id=46; 1 row updated. SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 1000123 AAAVmWAAEAAAEUbAAA 10001223 AAAVmWAAEAAAEUbAAB 28 AAAVmWAAEAAAEUbAAC 15 AAAVmWAAEAAAEUbAAD 29 AAAVmWAAEAAAEUbAAE 这些都是预期的结果,可见rownum还是有规律的。 我们切换会话到会话2 会话2: 查看rownum的情况,这个时候可以看到rownum的输出还是有规律可循的。只是为了保证一致性读,数据不同,但是rowid还是一致的。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 20 AAAVmWAAEAAAEUbAAA 46 AAAVmWAAEAAAEUbAAB 28 AAAVmWAAEAAAEUbAAC 15 AAAVmWAAEAAAEUbAAD 29 AAAVmWAAEAAAEUbAAE 看来不存在主键/唯一性索引的情况下,没有给我们带来太多惊喜,虽然有基本规律但是似乎都是意料之中。 我们来看看存在主键/唯一性索引的情况。 会话1: 我们创建唯一性索引。 SQL> create unique index ind_test_lock on test_lock(object_id); Index created. 这个时候rownum是按照对应的索引列来排列的,数据是有序的。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 2 AAAVmWAAEAAAEUbAAw 3 AAAVmWAAEAAAEUbAAF 4 AAAVmWAAEAAAEUbAAx 5 AAAVmWAAEAAAEUbAAa 6 AAAVmWAAEAAAEUbAAV 然后照例更新一行数据,object_id=2来看看。 update test_lock set object_id=10023420 where object_id=2; 可以看到rownum的情况,object_id是从下一行开始,即object_id=3 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 3 AAAVmWAAEAAAEUbAAF 4 AAAVmWAAEAAAEUbAAx 5 AAAVmWAAEAAAEUbAAa 6 AAAVmWAAEAAAEUbAAV 7 AAAVmWAAEAAAEUbAAR 这就有点意思了,这是不是有规律可循呢,我们再更新object_id=3的行 SQL> update test_lock set object_id=10023421 where object_id=3; 1 row updated. 再次查看rownum的情况,发现是从object_id=4开始输出了。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 4 AAAVmWAAEAAAEUbAAx 5 AAAVmWAAEAAAEUbAAa 6 AAAVmWAAEAAAEUbAAV 7 AAAVmWAAEAAAEUbAAR 8 AAAVmWAAEAAAEUbAAk 我们切换到会话2来看看数据情况。 会话2: SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 2 AAAVmWAAEAAAEUbAAw 3 AAAVmWAAEAAAEUbAAF 4 AAAVmWAAEAAAEUbAAx 5 AAAVmWAAEAAAEUbAAa 6 AAAVmWAAEAAAEUbAAV 可以看到会话2还是保留了原有的数据输出格式,还是从object_id=2开始。 切换回会话1: 会话1: 提交事务 SQL> commit; Commit complete. 这个时候下标就是从object_id=4开始了,在会话2中也是一样的输出结果。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 4 AAAVmWAAEAAAEUbAAx 5 AAAVmWAAEAAAEUbAAa 6 AAAVmWAAEAAAEUbAAV 7 AAAVmWAAEAAAEUbAAR 8 AAAVmWAAEAAAEUbAAk 我们来更新中间的一行数据,比如object_id=6看看是否依旧有规律。 SQL> update test_lock set object_id=10023422 where object_id=6; 1 row updated. 这个时候查看,发现object_id=6的记录好像从链表中删除了一样。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 4 AAAVmWAAEAAAEUbAAx 5 AAAVmWAAEAAAEUbAAa 7 AAAVmWAAEAAAEUbAAR 8 AAAVmWAAEAAAEUbAAk 9 AAAVmWAAEAAAEUbAAN 如果此时我们rollback SQL> rollback; Rollback complete. 这个时候object_id=6的数据又回来了。 SQL> select object_id ,rowid from test_lock where rownum<6; OBJECT_ID ROWID ---------- ------------------ 4 AAAVmWAAEAAAEUbAAx 5 AAAVmWAAEAAAEUbAAa 6 AAAVmWAAEAAAEUbAAV 7 AAAVmWAAEAAAEUbAAR 8 AAAVmWAAEAAAEUbAAk 由此可以看出rowid还是和数据的存储有很大的关系,和事务是有关联的,总之还是有一定的规律可循的。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2016-10-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Linyb极客之路

MySQL优化原理

如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图,有助于深入理解MySQL服务器。下图展示了MySQL的逻辑架构图。

2315
来自专栏Rgc

mysql数据库优化(二)

https://www.cnblogs.com/sevck/p/6733702.html

2042
来自专栏Java Web

Java 面试知识点解析(六)——数据库篇

1663
来自专栏LanceToBigData

MySQL优化原理

前言 说起MySQL的查询优化,相信大家收藏了一堆:不能使用SELECT *、不使用NULL字段、合理创建索引、为字段选择合适的数据类型..... 你是否真的理...

2619
来自专栏吴生的专栏

MySQL Optimization 优化原理

如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图,有助于深入理解MySQL服务器。下图展示了MySQL的逻辑架构图。

43415
来自专栏Java Web

Java 面试知识点解析(六)——数据库篇

在遨游了一番 Java Web 的世界之后,发现了自己的一些缺失,所以就着一篇深度好文:知名互联网公司校招 Java 开发岗面试知识点解析 ,来好好的对 Jav...

3279
来自专栏存储技术

MongoDB查询索引分析

最近几年,nosql数据库发展迅猛,mongo无疑是最闪耀的那颗明星;以前我们部门的系统,用到数据库时基本上mysql是标配;现在越来越多的项目都开始选择mon...

8296
来自专栏JAVA高级架构

万字总结:学习MySQL优化原理,这一篇就够了!

说起MySQL的查询优化,相信大家收藏了一堆奇技淫巧:不能使用SELECT *、不使用NULL字段、合理创建索引、为字段选择合适的数据类型..... 你是否真的...

1.1K8
来自专栏大闲人柴毛毛

Mysql性能优化

 1. 优化SQL   1)通过show status了解各种sql的执行频率         show status like 'Com_%' ...

40511
来自专栏软件开发

一个小时学会MySQL数据库

随着移动互联网的结束与人工智能的到来大数据变成越来越重要,下一个成功者应该是拥有海量数据的,数据与数据库你应该知道。

2273

扫码关注云+社区

领取腾讯云代金券