一。前言
通常，我们分页时怎么实现呢？
SELECT * FROM table ORDER BY id LIMIT 1000, 10;
但是，数据量猛增以后呢？
SELECT * FROM table ORDER BY id LIMIT 1000000, 10;
如上第二条查询时很慢的，直接拖死。
最关键的原因mysql查询机制的问题：
不是先跳过，后查询；
而是先查询，后跳过。(解释如下)
什么意思？比如limit 100000,10,在找到需要的那10条时，先会轮询经过前10W条数据，先回行查询出前100000条的字段数据，然后发现没用舍弃掉，直到最后找到需要的10条。
二。分析
limit offset,N, 当offset非常大时,效率极低,
原因是mysql并不是跳过offset行,然后单取N行,
而是取offset+N行,返回放弃前offset行,返回N行【同前边说的先查询，后跳过】.
效率较低,当offset越大时,效率越低
三。3条优化建议
1:从业务上去解决
办法:不允许翻过100页
以百度为例,一般翻页到70页左右.
2:不用offset,用条件查询.
例:
mysql> select id, from lx_com limit 5000000,10; +---------+--------------------------------------------+ | id | name | +---------+--------------------------------------------+ | 5554609 |温泉县人民政府供暖中心 | .................. | 5554618 |温泉县邮政鸿盛公司 | +---------+--------------------------------------------+ 10 rows in set (5.33 sec) mysql> select id,name from lx_com where id>5000000 limit 10; +---------+--------------------------------------------------------+ | id | name | +---------+--------------------------------------------------------+ | 5000001 |南宁市嘉氏百货有限责任公司 | ................. | 5000002 |南宁市友达电线电缆有限公司 | +---------+--------------------------------------------------------+ 10 rows in set (0.00 sec)
现象：从5.3秒到不到100毫秒，查询速度大大加快；但是数据结果却不一样
优点：利用where条件来避免掉先查询后跳过的问题，而是条件缩小范围，从而直接跳过。
存在问题: 有时有会发现用此方法与limitM,N，两次的结果不一致[如上边实例所展示]
原因:数据被物理删除过,有空洞.
解决:数据不进行物理删除(可以逻辑删除).
最终在页面上显示数据时,逻辑删除的条目不显示即可.
(一般来说,大网站的数据都是不物理删除的,只做逻辑删除 ,比如 is_delete=1)
3:延迟索引.
非要物理删除,还要用offset精确查询,还不限制用户分页,怎么办?
优化思路：
利用索引覆盖，快速查询出满足条件的主键id;然后凭借主键id作为where条件，达到快速查询。
（速度快在哪里？利用索引覆盖不需要回行就可以快速查询出满足条件的id，时间节约在这里了）
我们现在必须要查,则只查索引,不查数据,得到id.再用id去查具体条目.