在mysql中limit可以实现快速分页，但是如果数据到了几百万时我们的limit必须优化才能有效的合理的实现分页了，否则可能卡死你的服务器。当一个数据表中有几百万条数据的时候，就成问题了！

　　例如：SELECT * FROM student limit 0,10; 這个速度会很快，但是执行SELECT * FROM student limit 1000000,10;這个效率就及其低下了。这是为啥呢？原因是因为：当我们执行SQL语句的时候，一般都是从头开始查找也就是说，我们要查找10000020条以后的数据，那么必须先查询前100000020条数据，才能加载到后面的数据。所以，当我们查询的数据越靠后，使用這个方式进行查询的效率就会越低效。

　　为了解决這个问题，我们可以考虑一下這种方式：每次查询，都记录一下上次查询的最大ID，那么在下次查询的时候，只要从這个最大ID往后查找不就OK了。

　　日常分页SQL语句：select id,name,content from users order by id asc limit 100000,20    扫描100020行

   　如果记录了上次的最大ID：select id,name,content from users where id>100073 order by id asc limit 20 扫描20行。

　　很明显，下面的效率将会是上面的几百倍。

　　当一个数据库表过于庞大，LIMIT offset, length中的offset值过大，则SQL查询语句会非常缓慢，你需增加order by，并且order by字段需要建立索引。

   　 如果使用子查询去优化LIMIT的话，则子查询必须是连续的，某种意义来讲，子查询不应该有where条件，where会过滤数据，使数据失去连续性。

   　 如果你查询的记录比较大，并且数据传输量比较大，比如包含了text类型的field，则可以通过建立子查询。

        SELECT id,title,content FROM items WHERE id IN (SELECT id FROM items ORDER BY id limit 900000, 10);

        如果limit语句的offset较大，你可以通过传递pk键值来减小offset = 0，这个主键最好是int类型并且auto_increment

        SELECT * FROM users WHERE uid > 456891 ORDER BY uid LIMIT 0, 10;

         这条语句，大意如下:

       SELECT * FROM users WHERE uid >=  (SELECT uid FROM users ORDER BY uid limit 895682, 1) limit 0, 10;

       如果limit的offset值过大，用户也会翻页疲劳，你可以设置一个offset最大的，超过了可以另行处理，一般连续翻页过大，用户体验很差，则应该提供更优的用户体验给用户。