MySQL 最易碰到的性能问题就是数据量逐步增大之后的翻页速度变慢的额问题, 而且越往后翻页速度越慢, 如果用最快速的办法解决, 以下就是解决办法, 简单方便.
1, 问题现状
现有 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 秒, 如下:
- 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.
2, 问题分析
但是如果把上面的 SQL 稍微变动一下, 就会发现查询速度有质的飞跃, 如下:
- 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 条件语句都是使用了索引的, 这里没有问题, 但是查询结果不同, 利用了索引查询的语句中如果只包含了那个索引列 (覆盖索引), 那么这种情况会查询很快, 这里就是这种情况.
利用覆盖索引, 将查询语句需要扫描表的行数降低到最少, 即可降低查询时间.
3, 问题解决
按照上面的分析, 我们使用表连接的情况实现 SQL 优化, 如下:
- 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 秒, 达到优化目标.
来源: https://www.thinksaas.cn/group/topic/839444/