SQL优化:limit分页优化

分页查询

分页查询的问题点主要集中在

  1. 如何快速定位起始点
  2. 减少无用数据缓存

mysql为分页查询提供了很方便的关键字limit,但这个关键字在数据量较大时,却很低效。
“limit m,n”关键字的意思是,从第m行开始,扫描满足条件的n个偏移行。若需从第1行开始,则不需要指定m值。

示例

表aaaaa中共有2375690数据。

优化前的SQL

SQL执行结果:

SELECT DISTINCT(device_id) uid FROM aaaaa WHERE status = 0 LIMIT 88000,1000;
1000 rows in set (0.48 sec)

SQL执行计划:

MariaDB [star]> explain SELECT sql_no_cache DISTINCT(device_id) uid FROM aaaaa WHERE status = 0 LIMIT 88000,1000;
+------+-------------+---------------+------+---------------+------+---------+------+---------+------------------------------+
| id   | select_type | table         | type | possible_keys | key  | key_len | ref  | rows    | Extra                        |
+------+-------------+---------------+------+---------------+------+---------+------+---------+------------------------------+
|    1 | SIMPLE      | aaaaa         | ALL  | NULL          | NULL | NULL    | NULL | 2375690 | Using where; Using temporary |
+------+-------------+---------------+------+---------------+------+---------+------+---------+------------------------------+
优化方式

迅速定位起始ID,利用主键索引,加快扫描速度。可以看到,derived中,SQL使用到了覆盖索引进行扫描,虽然还是全表扫,因为只扫描id列,大大降低了扫描的IO耗费,快速定位到了id。

MariaDB [star]> explain SELECT sql_no_cache DISTINCT(device_id) uid FROM aaaaa join (select id from aaaaa limit 88000,1) k on star_device_5.id>=k.id where status=0 limit 1000; 
+------+-------------+---------------+-------+---------------+-------------+---------+------+---------+------------------------------------------------+
| id   | select_type | table         | type  | possible_keys | key         | key_len | ref  | rows    | Extra                                          |
+------+-------------+---------------+-------+---------------+-------------+---------+------+---------+------------------------------------------------+
|    1 | PRIMARY     |     | ALL   | NULL          | NULL        | NULL    | NULL |   88001 | Using temporary                                |
|    1 | PRIMARY     | star_device_5 | ALL   | PRIMARY       | NULL        | NULL    | NULL | 2377112 | Range checked for each record (index map: 0x1) |
|    2 | DERIVED     | star_device_5 | index | NULL          | idx_star_id | 8       | NULL | 2377112 | Using index                                    |
+------+-------------+---------------+-------+---------------+-------------+---------+------+---------+------------------------------------------------+

执行结果:

SELECT sql_no_cache DISTINCT(device_id) uid FROM star_device_5 join (select id from star_device_5 limit 880000,1) k on star_device_5.id>=k.id where status=0 limit 1000;
1000 rows in set (0.19 sec)

随着m的增大和n的增大,两种写法的SQL执行时间会有本质差别。我做了测试,当m值增加到880000时,优化前的SQL需要2分钟,优化后的SQL还是0.1s左右。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29730827/viewspace-2136208/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/29730827/viewspace-2136208/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值