最近写了好几篇与offset有关的文章，上一篇是解offset质变的问题。
<a href="https://yq.aliyun.com/articles/57730">https://yq.aliyun.com/articles/57730</a>
这一篇要解的是offset偏移量越大，越慢的问题。
offset偏移量很大的情况下，即使走的是索引（没有使用额外的sort），也会很慢，这是为什么呢？
.1. postgresql的索引里面没有版本信息，所以判断行是否可见，需要通过索引的ctid定位并访问到heap tuple，在tuple head中的信息，结合clog，snapshot等信息判断该tuple是否可见。
由于需要从 heap page判断tuple可见性，order by xx offset xx limit xx，offset的tuple全部都要扫一遍，offset偏移量越大越慢。
后来postgresql引入了visibility map，以及index only scan，对于没有dead tuple的heap page，从索引访问时，不需要到heap page判断行的可见性，如果大多数heap page都是clean的，可以降低额外的heap page scan的概率。
(visibility map用于记录heap page中是否有dirty tuple)
那么什么情况下所有的heap page都是clean的呢？ 如果表是insert only的，并且使用read uncommitted的隔离级别，那么就不需要到heap page判断可见性，直接读索引即可。
insert only table的index only scan + offset 这种应用场景，是可以从内核层面进行优化的，并且可以取得非常好的优化效果。
.2. 即使使用了index only scan，你会发现，postgresql扫描的page也比预想的多，并没有使用index leaf page的pt_next直接搜索next index page?
(下面的例子中会看到)
因为数据是只插入的，对于read uncommitted的事务隔离级别，不需要从heap中通过版本判断行是否对用户可见。
所以对于insert only table, read uncommitted 事务隔离级别，可以直接访问index。
insert only table + index only scan + 大量offset 场景.
测试表, 以及pk离散随机数据
索引和heap的pages占用
offset 1000000行，如果走index only scan，使用index page的"双向链表"进行index range scan， 理论上不需要访问747849 个数据块，btpageopaquedata中包含了左右block id，跨页访问不需要再回到root page。
但是从测试结果来看，确实访问了过多的数据块，即使是index only scan。
这是内核优化需要做的，把index only scan的page scan降低到实际需要扫的pages。
.1. 索引页中包含相邻page信息，结构如下，存放在index page的special space里面（index页尾）。
使用它来做index range scan可以大大降低本文提到的大批量数据扫描所需扫描的pages。
src/include/access/nbtree.h
.2. b-tree索引的叶子节点，相邻块并不一定是物理相邻的block，看例子：
叶子节点 block 1的相邻节点是block 100620，显然是不相邻的。
因此根据索引的范围查询，仅索引block的访问就是非常离散的，再加上heap page的访问，都是非常离散的。 好在索引页每一页都能放几百条，所以几百条的查询，实际上被访问的index page并不会太多。
.1. 对于查询结果可以直接在索引输出的，带上offset输出的话，可以用上 index only scan，但是从现在社区版本的情况来看，还有优化余地，至少能把需要访问的block下降。
postgresql的b-tree是类似"双向链表"的结构，内核层面根据index leaf page的btpo_next，实施index range scan，不需要额外的index page访问。
.2. 索引的leaf page(s)，branch page(s)都是离散的，只是逻辑结构上是树状的，同级page之间是通过类似双向链表的形式组织的。
因此index range scan时，index page扫描也是离散的。 比如做一个index only scan，offset一批数据或者直接scan一堆数据，都是离散的扫描。
.1. tuple，row
.2. ctid，行号（blocknum, 页内offset）
祝大家玩得开心，欢迎随时来阿里云促膝长谈业务需求 ，恭候光临。
阿里云的小伙伴们加油，努力做 最贴地气的云数据库 。