mysql limit在大数据量的场景就会遇到offset特别大的时候，性能明显下降的问题。limit 10000,20意味着扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行；问题就在这里，如果是limit 100000,100，需要扫描100100行，在一个高并发的应用里，每次查询需要扫描超过10W行，性能肯定大打折扣。

explain SELECT *FROM `waybill_histories`ORDER BY `id`limit 7183000, 500

以上这个sql的执行计划如下

id|select_type|table            |partitions|type |possible_keys|key    |key_len|ref|rows   |filtered|Extra|--+-----------+-----------------+----------+-----+-------------+-------+-------+---+-------+--------+-----+ 1|SIMPLE     |waybill_histories|          |index|             |PRIMARY|8      |   |4721845|   100.0|     |

从explain的结果显示sql扫描行的数量是很多的。

这种问题的解决思路核心就是要消除或者减少sql查找的数据范围，规避到offset带来的消耗。常见的方法就是“游标”。

游标可以理解成：用上一次查询的位置的位置，作为下一次查询的起点。

每次查询的结果包含一个游标值，下次查询的时候游标值作为查询参数之一。服务端查询的时候sql中加入游标值作为过滤条件。

explain SELECT *FROM `waybill_histories`where id>7183000limit 500

这个SQL的执行计划已经被大大改善

id|select_type|table            |partitions|type |possible_keys|key    |key_len|ref|rows |filtered|Extra      |--+-----------+-----------------+----------+-----+-------------+-------+-------+---+-----+--------+-----------+ 1|SIMPLE     |waybill_histories|          |range|PRIMARY      |PRIMARY|8      |   |23898|   100.0|Using where|

此外，服务端要根据这次查询结果找到max(id)作为游标值返回。