通常，我们会采用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执行耗时：
| yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 500, 10;…10 rows in set (0.05 sec)yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=6 ORDER BY id DESC LIMIT 935500, 10;…10 rows in set (2.39 sec) |
可以看到，随着分页数量的增加，SQL查询耗时也有数十倍增加，显然不科学。今天我们就来分析下，如何能优化这个分页方案。 一般滴，想要优化分页的终极方案就是：没有分页，哈哈哈~~~，不要说我讲废话，确实如此，可以把分页算法交给Sphinx、Lucence等第三方解决方案，没必要让MySQL来做它不擅长的事情。 当然了，有小伙伴说，用第三方太麻烦了，我们就想用MySQL来做这个分页，咋办呢？莫急，且待我们慢慢分析，先看下表DDL、数据量、查询SQL的执行计划等信息：
| yejr@imysql.com> SHOW CREATE TABLE `t1`;CREATE TABLE `t1` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT,... `ftype` tinyint(3) unsigned NOT NULL,... PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;yejr@imysql.com> select count(*) from t1;+----------+| count(*) |+----------+| 994584 |+----------+yejr@imysql.com> EXPLAIN SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 500, 10/G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: t1 type: indexpossible_keys: NULL key: PRIMARY key_len: 4 ref: NULL rows: 510 Extra: Using whereyejr@imysql.com> EXPLAIN SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935500, 10/G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: t1 type: indexpossible_keys: NULL key: PRIMARY key_len: 4 ref: NULL rows: 935510 Extra: Using where |
可以看到，虽然通过主键索引进行扫描了，但第二个SQL需要扫描的记录数太大了，而且需要先扫描约935510条记录，然后再根据排序结果取10条记录，这肯定是非常慢了。 针对这种情况，我们的优化思路就比较清晰了，有两点：
1、尽可能从索引中直接获取数据，避免或减少直接扫描行数据的频率
2、尽可能减少扫描的记录数，也就是先确定起始的范围，再往后取N条记录即可
据此，我们有两种相应的改写方法：子查询、表连接，即下面这样的：
#采用子查询的方式优化，在子查询里先从索引获取到最大id，然后倒序排，再取10行结果集
新闻热点
疑难解答
