解决MySQL数据量增大之后翻页慢问题

MySQL最易碰到的性能问题就是数据量逐步增大之后的翻页速度变慢的额问题,而且越往后翻页速度越慢,如果用最快速的办法解决,以下就是解决办法,简单方便。

Posted by shrmars on March 28, 2018

问题现状

现有MySQL数据表 event_data ,数据量 36.7万,如下:
mysql> select count(1) from event_data;
+———-+
| count(1) |
+———-+
| 367961 |
+———-+
1 row in set (0.05 sec)
使用SQL-Limit分页查询,需要花费时间382秒,如下:

1
2
3
4
5
6
SELECT a.*
     FROM event_data a
    WHERE a.receive_time >= '2018-03-28 00:00:00'
      AND a.receive_time <= '2018-03-28 23:59:59'
 ORDER BY a.receive_time DESC
    LIMIT 56280,15;

其中 receive_time 字段已建立索引,event_data 表的主键字段为 pk_id。

问题分析

但是如果把上面的SQL稍微变动一下,就会发现查询速度有质的飞跃,如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
mysql>    SELECT a.pk_id
   ->      FROM event_data a
   ->     WHERE a.receive_time >= '2018-03-28 00:00:00'
   ->       AND a.receive_time <= '2018-03-28 23:59:59'
   ->  ORDER BY a.receive_time DESC
   ->     LIMIT 56280,15;
+----------------------------------+
| pk_id                            |
+----------------------------------+
| ce7d990f39a4411c88ebb3240497e6f3 |
| bd47b1c380c946c39b3ec172a262823f |
| c1820a5633714a5e9a0b0c2abb092579 |
| d58456cbe16d4cc4a20645c1126fb9b7 |
| a1d786640ea048a7bd10bd9f12868d6d |
| f590aa4f26034dd9af2f4ba0d4f7430c |
| af3e81eb43b84467bd3e2c7ad31d6aff |
| 3ee331dce2064a788515986a0a97ac2b |
| 46f462dc4209499f90dad2dc4076e4ca |
| 8ebb7ff55bc443e4854e583f6dc37ff7 |
| 883fd68d93dc49eab5b35ebf9ab8f8ee |
| 932c264d6dd140f3ac4f07f3410ce147 |
| 19b6426cdd664fe2983166e0cca93c53 |
| 3a0bfa4e000e4b69bba1a6bed6545973 |
| 5640a162380346f19d57a61c1dc0dd42 |
+----------------------------------+
15 rows in set (0.03 sec)

查询结果返回只需要30毫秒,虽然SQL变动很小,只是将查询结果 由 a.* 改为了 a.pk_id,但是速度的提升是巨大的。
原因分析:两条SQL where 条件语句都是使用了索引的,这里没有问题,但是查询结果不同,利用了索引查询的语句中如果只包含了索引列(覆盖索引),那么这种情况会查询很快,这里就是这种情况。
利用覆盖索引,将查询语句需要扫描表的行数降低到最少,即可降低查询时间。
问题解决
按照上面的分析,我们使用表连接的情况实现SQL优化,如下:

1
2
3
4
5
6
7
8
9
10
select a.* FROM (
            SELECT pk_id
              FROM event_data c
             WHERE c.receive_time >= '2018-03-28 00:00:00'
               AND c.receive_time <= '2018-03-28 23:59:59'
                    ORDER BY c.receive_time DESC
             LIMIT 56280,15
                ) b
      left join event_data a
             on a.pk_id=b.pk_id

执行时间为0.048秒,达到优化目标。