面试官：如何优雅的从千万级数据中获取你想要的？我只用了5毫秒....

bokersy:
不讲原理的话用处不大，为什么索引能快？需要明白聚集索引和辅助索引 索引结构： - 聚集索引的叶子节点存的是全表字段 - 辅助索引只存索引的字段及其对应的主键 查聚集索引是全表扫描 所以为什么辅助索引更快呢？从上边的索引结构就能得到答案了，先走体量小的辅助索引，那么只需要很少次的磁盘IO，就可以拿到对应行数据。 在此基础上，如果需要全表字段，那么根据这些ID去回表就行了。 这个时候你可能回说，如果回表查询范围很大，且这些需要回表的 ID 是无序且离散的怎么办呢？这个时候就要提到 MMR 优化了，这是MySQL 自己做的优化操作，它会把需要回表操作的 ID 排序，将无需的、离散的多个小IO 尽可能的合并成大IO，从而提高回表的效率。———————— 以上内容基于 MySQL 的 Innodb 引擎

【回复】无需的、离散的 ===> 无序的、离散的
滋补需谨慎:
那种id的方式看到好多次了 这种方式在程序里根本没法用啊 用户跳页操作咋知道从哪个id开始 id肯定不会连续

【回复】亲，这边如果有一千万条数据提供给用户进行任意分页查询，并且还需要支持高并发的话，这边建议您直接换搜索引擎存储哦。mysql是做不到这个能力的。 一般这种优化都是在内部后台系统，可以通过强制性的加上条件，比如年份，月份啥的，来做搜索。或者在大批量数据中，通过这种方式来循环处理数据。你那种场景建议直接换搜索引擎，mysql压根做不到。
【回复】[doge]大多分页优化都这样
【回复】没有哪个技术能适用于全部的业务场景，但有它适用的场景。你可以看下京东，淘宝，这些平台商品数据肯定巨大，你去他们网站会发现，根本没有显示页数，第几页之类的功能。因为这都是经过分页优化的，不由用户来控制
月半55开:
目前一种就是先把id 查出来然后关联查询，如果还慢就只能找前端配合，把前5页id 和后5页id 给前端，前端跳转页限制不能跳超过5页，反正这玩意实际搞起来也挺麻烦