109-特定场景深度分页SQL优化技巧

newkid

sql_tigerliu 发表于 2023-9-3 18:58
这种东西不可能是通用的 ， 你的这个场景可以拆分成union all。 文章的场景用来优化本论坛可行否？

如果多个 owner 做查询条件，事先算好的序号就用不上了，union all 也不行。以我们公司为例，所有的分页界面都有灵活的组合查询条件和排序方式，有很多连接和聚合，所以文中提到的技巧，适用范围是非常有限的。

newkid

关于连续序号的讨论，在 asktom 上面有很多讨论，比如：
https://asktom.oracle.com/pls/ap ... ag=sequences-200206

顺便说一句，刘老师上面说的关于物化视图的一次性全量刷新的开销，其实并不是一次性，而是每天刷新都会发生。

〇〇

还有一种是把前几页读出来，缓存在应用里

newkid

如果只是“前几页”，那根本不是问题，传统的做法就很好，应用不缓存也无所谓。
这篇文章的重点是深度翻页，当N很大时，要得到第N页，用传统做法数据库不得不读取1~N页。所以他加了一个序号其实是事先把分页结果给存在表中。
而我上面的观点是，当N很大时，精 确定位到第N页没有实用意义，是个伪需求。
我上面帖子提到的末页导航，不过是反向排序而已，实际上还是取的前几页。

sql_tigerliu

newkid 发表于 2023-9-4 00:46
关于连续序号的讨论，在 asktom 上面有很多讨论，比如：https://asktom.oracle.com/pls/apex/asktom.search ...

对于静态历史数据， 也是可以不用刷新的。 这个要看具体的业务场景。比如OA系统浏览2023年之前的历史记录， 创建一个mv也花不了几分钟， 然后就可以给所有人随便用了。 当然想实现随机组合的查询就不要想了，可以根据常用的查询组合创建一些mv， 特别是对历史静态数据的查询；

sql_tigerliu

newkid 发表于 2023-9-4 08:37
如果只是“前几页”，那根本不是问题，传统的做法就很好，应用不缓存也无所谓。这篇文章的重点是深度翻页， ...

大部分深度分页需求都是因为产品经理不了解这里面的性能大坑，随便答应给客户做的。随着数据量的增加，客户就会发现想随意跳转会越来越困难。深度分页的绝大部分需求都是不太合理的， 我给的建议是通过增加查询条件（比如日期范围等）来避免生成大的结果集， 这个才是解决深度分页的**方法。如果客户确有需求， 那就要好好设计一下了， 我这个文章也是抛砖引玉， 提供了一个思路。