MySQL分页导致的线上事故分析( 三 )

 
这个效率是最好的,无论怎么分页,耗时基本都是一致的,因为他执行完条件之后,都只扫描了25条数据 。
 
但是有个问题,只适合一页一页的分页,这样才能记住前一个分页的最后Id 。如果用户跳着分页就有问题了,比如刚刚刷完第25页,马上跳到35页,数据就会不对 。
 
这种的适合场景是类似百度搜索或者腾讯新闻那种滚轮往下拉,不断拉取不断加载的情况 。这种延迟加载会保证数据不会跳跃着获取 。
 
3、降级策略
 
看了网上一个阿里的dba同学分享的方案:配置limit的偏移量和获取数一个最大值,超过这个最大值,就返回空数据 。
 
因为他觉得超过这个值你已经不是在分页了,而是在刷数据了,如果确认要找数据,应该输入合适条件来缩小范围,而不是一页一页分页 。
 
这个跟我同事的想法大致一样:request的时候 如果offset大于某个数值就先返回一个4xx的错误 。
 
六、小结
 
当晚我们应用上述第三个方案,对offset做一下限流,超过某个值,就返回空值 。第二天使用第一种和第二种配合使用的方案对程序和数据库脚本进一步做了优化 。
 
合理来说做任何功能都应该考虑极端情况,设计容量都应该涵盖极端边界测试 。
 
另外,该有的限流、降级也应该考虑进去 。比如工具多线程调用,在短时间频率内8000次调用,可以使用计数服务判断并反馈用户调用过于频繁,直接给予断掉 。
 
哎,大意了啊,搞了半夜,QA同学不讲武德 。
 
----文章来源网络 。

【MySQL分页导致的线上事故分析】


推荐阅读