[MySQL优化案例]系列 — 分页优化

时间  2019-11-11
标签 mysql 优化 案例 系列 分页 栏目 MySQL 繁體版
原文   原文链接

一般，咱们会采用ORDER BY LIMIT start, offset 的方式来进行分页查询。例以下面这个SQL：mysql

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执行耗时：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: index
possible_keys: NULL
 key: PRIMARY
 key_len: 4
 ref: NULL
 rows: 510
 Extra: Using where

yejr@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: index
possible_keys: NULL
 key: PRIMARY
 key_len: 4
 ref: NULL
 rows: 935510
 Extra: Using where

能够看到，虽然经过主键索引进行扫描了，但第二个SQL须要扫描的记录数太大了，并且须要先扫描约935510条记录，而后再根据排序结果取10条记录，这确定是很是慢了。 针对这种状况，咱们的优化思路就比较清晰了，有两点：优化

一、尽量从索引中直接获取数据，避免或减小直接扫描行数据的频率
二、尽量减小扫描的记录数，也就是先肯定起始的范围，再日后取N条记录便可

据此，咱们有两种相应的改写方法：子查询、表链接，即下面这样的：排序

#采用子查询的方式优化，在子查询里先从索引获取到最大id，而后倒序排，再取10行结果集
#注意这里采用了2次倒序排，所以在取LIMIT的start值时，比原来的值加了10，即935510，不然结果将和原来的不一致
yejr@imysql.com> EXPLAIN SELECT * FROM (SELECT * FROM `t1` WHERE id > ( SELECT id FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) t ORDER BY id DESC\G
*************************** 1. row ***************************
 id: 1
 select_type: PRIMARY
 table: <derived2>
 type: ALL
possible_keys: NULL
 key: NULL
 key_len: NULL
 ref: NULL
 rows: 10
 Extra: Using filesort
*************************** 2. row ***************************
 id: 2
 select_type: DERIVED
 table: t1
 type: ALL
possible_keys: PRIMARY
 key: NULL
 key_len: NULL
 ref: NULL
 rows: 973192
 Extra: Using where
*************************** 3. row ***************************
 id: 3
 select_type: SUBQUERY
 table: t1
 type: index
possible_keys: NULL
 key: PRIMARY
 key_len: 4
 ref: NULL
 rows: 935511
 Extra: Using where

#采用INNER JOIN优化，JOIN子句里也优先从索引获取ID列表，而后直接关联查询得到最终结果，这里不须要加10
yejr@imysql.com> EXPLAIN SELECT * FROM `t1` INNER JOIN ( SELECT id FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935500,10) t2 USING (id)\G
*************************** 1. row ***************************
 id: 1
 select_type: PRIMARY
 table: <derived2>
 type: ALL
possible_keys: NULL
 key: NULL
 key_len: NULL
 ref: NULL
 rows: 935510
 Extra: NULL
*************************** 2. row ***************************
 id: 1
 select_type: PRIMARY
 table: t1
 type: eq_ref
possible_keys: PRIMARY
 key: PRIMARY
 key_len: 4
 ref: t2.id
 rows: 1
 Extra: NULL
*************************** 3. row ***************************
 id: 2
 select_type: DERIVED
 table: t1
 type: index
possible_keys: NULL
 key: PRIMARY
 key_len: 4
 ref: NULL
 rows: 973192
 Extra: Using where

而后咱们来对比下这2个优化后的新SQL执行时间：索引

yejr@imysql.com> SELECT * FROM (SELECT * FROM `t1` WHERE id > ( SELECT id FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) T ORDER BY id DESC;
...
rows in set (1.86 sec)
#采用子查询优化，从profiling的结果来看，相比原来的那个SQL快了：28.2%

yejr@imysql.com> SELECT * FROM `t1` INNER JOIN ( SELECT id FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935500,10) t2 USING (id);
...
10 rows in set (1.83 sec)
#采用INNER JOIN优化，从profiling的结果来看，相比原来的那个SQL快了：30.8%

咱们再来看一个不带过滤条件的分页SQL对比：get

#原始SQL
yejr@imysql.com> EXPLAIN SELECT * FROM `t1` ORDER BY id DESC LIMIT 935500, 10\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 935510
        Extra: NULL

yejr@imysql.com> SELECT * FROM `t1` ORDER BY id DESC LIMIT 935500, 10;
...
10 rows in set (2.22 sec)

#采用子查询优化
yejr@imysql.com> EXPLAIN SELECT * FROM (SELECT * FROM `t1` WHERE id > ( SELECT id FROM `t1` ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) t ORDER BY id DESC;
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: <derived2>
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10
        Extra: Using filesort
*************************** 2. row ***************************
           id: 2
  select_type: DERIVED
        table: t1
         type: ALL
possible_keys: PRIMARY
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 973192
        Extra: Using where
*************************** 3. row ***************************
           id: 3
  select_type: SUBQUERY
        table: t1
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 935511
        Extra: Using index

yejr@imysql.com> SELECT * FROM (SELECT * FROM `t1` WHERE id > ( SELECT id FROM `t1` ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) t ORDER BY id DESC;
…
10 rows in set (2.01 sec)
#采用子查询优化，从profiling的结果来看，相比原来的那个SQL快了：10.6%


#采用INNER JOIN优化
yejr@imysql.com> EXPLAIN SELECT * FROM `t1` INNER JOIN ( SELECT id FROM `t1`ORDER BY id DESC LIMIT 935500,10) t2 USING (id)\G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: 
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 935510
        Extra: NULL
*************************** 2. row ***************************
           id: 1
  select_type: PRIMARY
        table: t1
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: t1.id
         rows: 1
        Extra: NULL
*************************** 3. row ***************************
           id: 2
  select_type: DERIVED
        table: t1
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 973192
        Extra: Using index

yejr@imysql.com> SELECT * FROM `t1` INNER JOIN ( SELECT id FROM `t1`ORDER BY id DESC LIMIT 935500,10) t2 USING (id);
…
10 rows in set (1.70 sec)
#采用INNER JOIN优化，从profiling的结果来看，相比原来的那个SQL快了：30.2%

至此，咱们看到采用子查询或者INNER JOIN进行优化后，都有大幅度的提高，这个方法也一样适用于较小的分页，虽然LIMIT开始的 start 位置小了不少，SQL执行时间也快了不少，但采用这种方法后，带WHERE条件的分页分别能提升查询效率：24.9%、156.5%，不带WHERE条件的分页分别提升查询效率：554.5%、11.7%，各位能够自行进行测试验证。单从提高比例说，仍是挺可观的，确保这些优化方法能够适用于各类分页模式，就能够从一开始就是用。 咱们来看下各类场景相应的提高比例是多少：io

  大分页，带WHERE 大分页，不带WHERE 大分页平均提高比例 小分页，带WHERE 小分页，不带WHERE 整体平均提高比例
子查询优化 28.20% 10.60% 19.40% 24.90% 554.40% 154.53%
INNER JOIN优化 30.80% 30.20% 30.50% 156.50% 11.70% 57.30%

结论：这样看就和明显了，尤为是针对大分页的状况，所以咱们优先推荐使用INNER JOIN方式优化分页算法。table

上述每次测试都重启mysqld实例，而且加了SQL_NO_CACHE，以保证每次都是直接数据文件或索引文件中读取。若是数据通过预热后，查询效率会必定程度提高，但但上述相应的效率提高比例仍是基本一致的。

2014/07/28后记更新：

其实若是是不带任何条件的分页，就不必用这么麻烦的方法了，能够采用对主键采用范围检索的方法，例如参考这篇：Advance for MySQL Pagination

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程