今天要讨论一个传统的问题，问题本身比较简单，就是针对大数据，如何优化方案做到性能与成本的平衡。我们经常会遇到一种Key-list类型数据， 如一个用户的好友关系 {“uid”:{1,2,3,4,5}}，表示uid包含有5个好友；一条微博下面的评论id列表{“weibo_id”: {comment_id1, comment_id2……}}，一个用户发表的微博id列表等。 在list长度较少时候，我们可以直接的使用数据库的翻页功能，如
根据经验，在大部分场景下，单个业务的list数据长度99%在1000条以下，在数据规模较小时候，上面的方法非常适合。但剩下的1%的数据可能多达100万条，在数据规模较大的时候，当访问offset较大的数据，上述方法非常低效（可参看Why does MYSQL higher LIMIT offset slow the query down?），但在实现方案的时候不能忽视这些超大数据集的问题，因此要实现一个适合各种变长list的翻页方案，考虑到数据的长尾问题，并没有简单高效的方案。这也体现了常说的80%+的时间在优化20%-的功能。 List数据访问模型常见的有两种方式 1. 扶梯方式扶梯方式在导航上通常只提供上一页/下一页这两种模式，部分产品甚至不提供上一页功能，只提供一种“更多/more”的方式，也有下拉自动加载更多的方式，在技术上都可以归纳成扶梯方式。
（图：blogspot的导航条）
（图：很多瀑布流式的产品只提供一个more的导航条） 扶梯方式在技术实现上比较简单及高效，根据当前页最后一条的偏移往后获取一页即可，在MySQL可使用以下方法实现。
由于where条件中指定了位置，因此算法复杂度是O(log n) 2. 电梯方式另外一种数据获取方式在产品上体现成精确的翻页方式，如1,2,3……n，同时在导航上也可以由用户输入直达n页。国内大部分产品经理对电梯方式有特殊的喜好，如图
但电梯方式在技术实现上相对成本较高，当使用以下SQL时
我们可以使用MySQL explain来分析，从下文可以看到，当offset=10000时候，实际上MySQL也扫描了10000行记录。
|
