为什么会这样？在MySQL中，索引通常是b-tree方式（但存储引擎如InnoDB实际是b+tree），如图
从图中可以看到，使用电梯方式时候，当用户指定翻到第n页时候，并没有直接方法寻址到该位置，而是需要从第一楼逐个count，scan到 count*page时候，获取数据才真正开始，所以导致效率不高。对应的算法复杂度是O(n)，n指offset，也就是page*count。 另外Offset并不能有效的缓存，这是由于 1、在数据存在新增及删除的情况下，只要有一条变化，原先的楼层可能会全部发生变化。在一个用户并发访问的场景，频繁变化的场景比较常见。 2、电梯使用比较离散，可能一个20万条的list，用户使用了一次电梯直达100楼之后就走了，这样即使缓存100楼之下全部数据也不能得到有效利用。 以上描述的场景属于单机版本，在数据规模较大时候，互联网系统通常使用分库的方式来保存，实现方法更为复杂。 在面向用户的产品中，数据分片通常会将同一用户的数据存在相同的分区，以便更有效率的获取当前用户的数据。如下图所示
（图：数据按用户uid进行hash拆分） 图中的不同年份的数据的格子是逻辑概念，实际上同一用户的数据是保存在一张表中。因此方案在常见的使用场景中存在很大不足，大部分产品用户只访问最 近产生的数据，历史的数据只有极小的概率被访问到，因此同一个区域内部的数据访问是非常不均匀，如图中2014年生成的属于热数据，2012年以前的属于 冷数据，只有极低的概率被访问到。但为了承担红色部分的访问，数据库通常需要高速昂贵的设备如SSD，因此上面方案所有的数据都需要存在SSD设备中，即 使这些数据已经不被访问。 简单的解决方案是按时间远近将数据进行进一步分区，如图。
注意在上图中使用时间方式sharding之后，在一个时间分区内，也需要用前一种方案将数据进行sharding，因为一个时间片区通常也无法用一台服务器容纳。 上面的方案较好的解决了具体场景对于key list访问性能及成本的平衡，但是它存在以下不足
由于以上问题，尤其是二级索引的引入，显然它不是理想中的key list实现，后文继续介绍适合大数据翻页key list设计的一些思路及尝试。 |
