我就废话不多说了，看代码吧~

select
  row_number() over(order by 业务号,主键,排序号) rn -- 行号
  ,count(0) over() cnt -- 总条数
  ,id

from 表

order by 排序号,主键,业务号

offset (页号- 1)* 每页数量 limit 每页数量

补充：postgreSQL单表数据量上千万分页查询缓慢的优化方案

故事要这样说起，王铁蛋是一个初入职场的程序猿，每天干的活就是实现各种简单的查询业务，但是铁蛋有一颗热爱技术的心，每天都琢磨着如何写出花式的增删改查操作。没错平凡的铁蛋的有着唐山快照优化一个伟大的梦想，成为一名高级CRUDER。（一不小心激动了，开水倒进了我的花瓶）。

时间就这样一天天的流逝，铁蛋感觉不管自己的crud写的再花骚也不能达到高级cruder的级别，于是乎铁蛋心一横，接下了一个艰巨的任务，对单表数据量到百万千万级别的查询页面进行优化，这是铁蛋工作任务上的一小步，却是铁蛋实现梦想的一大步。

接任务简单，做任务难呀！ 这是铁蛋第一天的感受，接了这个任务之后铁蛋没有一点头绪，从哪下手呢？铁蛋仔细一想既然要优化，那么总得知道 哪里需要优化吧？ 可以从哪些方面优化吧？ 需要知道最如何分析瓶颈在哪吧？ 不料天降神图，给了铁蛋一个指引， 没错就是数据库可以优化的方向图。

注：图中效果的渐变其实不太准确， 但是总的来说如果不是SQL写的特别烂的话大体上优化这些不同的方面对性能的影响是以图中的示意变化的。

虽然有了神图的指引，但是铁蛋还是不知道应该优化哪个方面？ 不同方面的优化方式是什么？经过铁蛋的一番努力查找（哈哈，这次不是上天相助了，总要努力下的， 不然这黑幕太明显了），得到了以下信息：

从成本方面考虑，土豪的优化方式向来简单粗暴，硬件不行就换硬件嘛, 不差钱！！！ 但是铁蛋不行呀，草根一枚，要钱没钱， 要人没人，只能选择便宜的来下手了。柿子嘛还是得挑软的捏，于是乎，铁蛋踌躇满志的找产品商量改需求。

咳咳 ！！！！怎么说呢？ 铁蛋是为了降低成本，为公司控本降费，初心是好的，但是呀这个做法嗯嗯啊啊。。。， 大家以此为戒哦！！！

既然改需求不行，那就只能往下走了， 先来一波SQL优化看看，要优化SQL总得知道SQL慢在哪里了吧？

咋办咋办！ 不知道哪里慢咋办？

还能咋办，看SQL的执行计划呗！

不会看咋办？

啥！ 不会看， 不会看学啊！

好吧，当我没问！！！

怎么看执行计划呢，首先你得会一个SQL的命令，叫EXPLAIN, 此命令用于查看SQL的执行计划。得此命令，铁蛋如获至宝， 拿起来就是一顿操作，看到命令输出的结果后，铁蛋傻眼了，这什么鬼？ 这怎么看？