炸！业界困难，跨库分页的几种常见方案

弱点显而易见：

• 每个分库必要返回更多的数据，增大了收集传输量(耗收集);
• 除了数据库凭证time举办排序，处事层还必要举办二次排序，增大了处事层的计较劲(耗CPU);
• 最致命的，这个算法跟着页码的增大，机能会急剧降落，这是由于SQL改写后每个分库要返回X+Y行数据：返回第3页，offset中的X=200;若是要返回第100页，offset中的X=9900，即每个分库要返回100页数据，数据量和排序量都将大增，机能平方级降落。

“全局视野法”固然机能较差，但其营业无损，数据精准，不失为一种方案，有没有机能更优的方案呢?

“任何离开营业的架构计划都是耍混混”，技能方案必要折衷，在技能难度较大的环境下，营业需求的折衷可以或许极大的简化技能方案。

方案二：榨取跳页查询法

在数据量很大，翻页数许多的时辰，许多产物并不提供“直接跳到指定页面”的成果，而只提供“下一页”的成果，这一个小小的营业折衷，就能极大的低落技能方案的伟大度。

如上图，不能跳页，那么第一次只可以或许查第一页：

(1)将查询

order by time offset 0 limit 100; 

改写成

order by time where time>0 limit 100; 

(2)上述改写和offset 0 limit 100的结果沟通，都是每个分库返回了一页数据(上图中粉色部门);

(3)处事层获得2页数据，内存排序，取出前100条数据，作为最终的第一页数据，这个全局的第一页数据，一样平常来说每个分库都包括一部门数据(如上图粉色部门);

这个方案也必要处事器内存排序，岂不是和“全局视野法”一样么?第一页数据的拉取确实一样，但每一次“下一页”拉取的方案就纷歧样了。

点击“下一页”时，必要拉取第二页数据，在第一页数据的基本之上，可以或许找到第一页数据time的最大值：

这个上一页记录的time_max，会作为第二页数据拉取的查询前提：

(1)将查询

order by time offset 100 limit 100; 

改写成

order by time where time>$time_max limit 100; 

(2)这下不是返回2页数据了(“全局视野法，会改写成offset 0 limit 200”)，每个分库照旧返回一页数据(如上图中粉色部门);

(3)处事层获得2页数据，内存排序，取出前100条数据，作为最终的第2页数据，这个全局的第2页数据，一样平常来说也是每个分库都包括一部门数据(如上图粉色部门);

云云来去，查询全局视野第100页数据时，不是将查询前提改写为

offset 0 limit 9900+100;（返回100页数据） 

而是改写为

time>$time_max99 limit 100;（仍返回一页数据） 

以担保数据的传输量和排序的数据量不会跟着不绝翻页而导致机能降落。

方案三：应承数据精度丧失法

“全局视野法”可以或许返回营业无损的准确数据，在查询页数较大，譬喻第100页时，会有机能题目，此时营业上是否可以或许接管，返回的100页不是精准的数据，而应承有一些数据毛病呢?

先来相识一下，数据库分库-数据平衡道理。

什么是，数据库分库-数据平衡道理?

行使patition key举办分库，在数据量较大，数据漫衍足够随机的环境下，各分库全部非patition key属性，在各个分库上，数据漫衍的统计概率环境是同等的。

譬喻，在uid随机的环境下，行使uid取模分两库，db0和db1：

• 性别属性，假如db0库上的男性用户占比70%，则db1上男性用户占比也应为70%;
• 年数属性，假如db0库上18-28岁少女用户比例占比15%，则db1上少女用户比例也应为15%;
• 时刻属性，假如db0库上天天10:00之前登录的用户占比为20%，则db1上应该是沟通的统计纪律;
• …

操作这一道理，要查询全局100页数据，只要将：

offset 9900 limit 100; 

改写为

offset 4950 limit 50; 

即每个分库偏移一半(4950)，获取半页数据(50条)，获得的数据集的并集，根基可以或许以为，是全局数据的offset 9900 limit 100的数据，虽然，这一页数据并不是精准的。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!