排查问题发现线上mysql有个表数据量达到了1.4kw，观察了下，日增量大概40-50w的样子

突然联想到一个场景，如果我要拿这1.4kw数据中的最后十条怎么办（这就是所谓的深度分页）

本着理科生有问题解决问题，没问题制造问题来解决的心态

开始了性能压榨

先来看常规查询（公平起见，全部用select *）

我的天，用了19s，这要是再结合一些复杂查询，不得30+s，这谁顶得住啊

分析原因

不用想，这个sql肯定是没走索引了

看type类型，ALL代表进行了全表扫描

试图优化

既然没走索引那我就让你走索引
看了下表结构，只有一个字段建了索引，哪个字段我就不说了，秘密，我就直接用主键吧

select * 没走索引，那select id呢

时间缩短了不少，但是我想要所有字段，不可能只查id啊

所以

这不就妥了，我先查id，再通过id拿其它字段，靠谱~

到现在，原本 19s 的 sql 已经缩短到3s，nice

看下执行计划，我们得知道为啥变快了

看几个关键字段，type、key、extra，不算完美，但也还行，毕竟我们这种非DBA选手，sql能力有限

顺便科普下这个执行计划，看id列，1 1 2，执行顺序是第三行 第一行 第二行，记住口诀：id不同大的先走，id相同，从上往下
所以第一行中type列的ALL并不是指进行了全部扫描，而是表示对子查询中的结果集进行了全部扫描，很合理

关于详细执行计划，出门右转 mysql执行计划explain属性解析

一千四百万数据量深度分页能3秒，算不错了，但是还能不能继续优化？

能

教你个绝活，老板见了都要激动的拍打轮椅

你没有看错，就是0.036s，刺不刺激

虽然性能嘎嘎猛，但局限性太大，首先你得是自增id，并且id不能有断层，这对表维护要求很高，每次删除了数据都得清一下旧id，就图个乐吧，量大了老老实实上es、ck，要么就让你的用户接受查询慢一点

总结

//常规分页
SELECT * FROM table_name limit 14000000,10//耗时19.426s

//先查id ，写法很多，看个人习惯
SELECT * FROM table_name a,(SELECT id FROM table_name limit 14000000,10) b WHERE a.id = b.id  //耗时3.068

//如果你的表有自增id(并且没断层)，就这么写，效率直接起飞
SELECT * FROM table_name WHERE id>14000000 LIMIT 10  //耗时0.036

完结
撒花

---

ok我话说完