通常，我们会采用ORDER BY LIMIT start, offset 的方式来进行分页查询。例如下面这个SQL：
SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 100, 10;
或者像下面这个不带任何条件的分页SQL：
SELECT * FROM `t1` ORDER BY id DESC LIMIT 100, 10;
一般而言，分页SQL的耗时随着 start 值的增加而急剧增加，我们来看下面这2个不同起始值的分页SQL
当需要从数据库查询的表有上万条记录的时候，一次性查询所有结果会变得很慢，特别是随着数据量的增加特别明显，这时需要使用分页查询。对于数据库分页查询，也有很多种方法和优化的点。下面简单说一下我知道的一些方法。
准备工作
为了对下面列举的一些优化进行测试，下面针对已有的一张表进行说明。
表名：order_history
描述：某个业务的订单历史表
主要字段：unsigned int id，tinyint(4) int type
字段情况：该表一共37个字段，不包含text等大型数组，最大为varcha
发现问题
当我们展示一个列表中的内容时，难免会遇到分页问题，因为列表中的内容数量可能很多，但是用户能一次看到的界面大小是有限的，不可能一个界面展示所有的内容，从后端一次性取太多的数据也会给后端造成额外的压力。
通常分页查询的时候会使用这样的语句：
SELECT
*
FROM table
where condition1 = 0
and condition2 = 0
and condition3 = -1
and condition4 = -1
order by id asc
LIMIT 20
在对大表进行分页时，如果在服务端实现分页，大多数情况采用SQL的limit语法来实现。但是当页数越来越大时，性能很可能成为问题，尤其是需要查询表的所有字段。
1. 索引与非索引字段
在查询的结果集中，如果只包含索引字段，性能相比于包含非索引字段，差别很大。下面是一个简单的例子，在大约50w行的表上操作：
只查询索引id字段
SELECT id FROM test.bas_table
limit 400000，1000;
– 0.094 second
查询
传统的mysql分页查询
select * from table limit n , m
MySQL 执行此类SQL时需要先分页(默认一页1000条数据)通过全表扫描到N行，然后再去取M行。对于此类操作，获取前面少数几行数据会很快，但是随着扫描的记录数越多，SQL的性能就会越差，因为N的值越大，MySQL需要扫描越多的数据来定位到具体的N行，这样耗费大量的 IO 成本和时间成本。
特别是上线后数据量积累比较快,必须重视SQL优化,否则影响系统运行和用户使用体验
性能实验
直接用limit sta
