MySQL Limit数据不足时导致查询变慢

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u014440417/article/details/80352550

问题

有如下一个查询:
查询SQL:

select * from tb_record where ctime < 1524758400 AND AND type in (2,4,6,8) id > 131946599 order by id asc limit 1000;

统计SQL:

select count(*) from tb_record where  ctime < 1524758400 AND AND type in (2,4,6,8) id > 131946599 order by id asc;

前提:表中id > 131946599的数据量级在千万级。扫描后面的数据耗时长。

当统计SQL的数据大于limit的量(1000)时,查询很快。1s左右能出结果。
当统计SQL的数据量小于1000时,查询就很慢。超时都出不来。

原因

因为如果符合条件的数据足够多,则limit1000的过程就是,从符合条件的第一条数据开始往后查,当查够1000条数据,则立刻返回。

如果符合条件的数据不够,则会从符合条件的第一条数据开始往后扫描,一条条的查,直到把整个表扫描完仍然不够1000条,才会返回结果(不够1000条)。

解决方案:

方案一:

查出满足条件的数据一共有多少条,按照条数处理,最后一个Limit的数量剩余满足条件的数量。
但是,如果查询条件没有索引,统计总共有多少条的将会是个慢查询。

方案二:

类似滑动窗口的方式,每次对id查询idStart+1000=idEnd范围内的符合条件的数据。凑够1000条的时候返回,但是业务实现就会更加复杂。

mysql limit 导致索引选择 问题

10-21

有limit的时候,选择索引 heats 导致结果集非常大。rn[code=sql]explain SELECT DISTINCT t.* FROM `pre_forum_thread` as t WHERE t.tid > 498405 AND t.readperm='0' AND t.tid NOT IN ('492187','513918') AND t.isgroup='0' AND t.dateline >= '1413771125' AND t.heats>'0' AND t.displayorder>='0' ORDER BY t.heats DESC limit 0,9 ;rn+----+-------------+-------+-------+-----------------------+-------+---------+------+--------+-------------+rn| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |rn+----+-------------+-------+-------+-----------------------+-------+---------+------+--------+-------------+rn| 1 | SIMPLE | t | range | PRIMARY,heats,isgroup | heats | 4 | NULL | 374891 | Using where |rn+----+-------------+-------+-------+-----------------------+-------+---------+------+--------+-------------+[/code]rn去掉limit使用主键索引,rn[code=sql]explain SELECT DISTINCT t.* FROM `pre_forum_thread` as t WHERE t.tid > 498405 AND t.readperm='0' AND t.tid NOT IN ('492187','513918') AND t.isgroup='0' AND t.dateline >= '1413771125' AND t.heats>'0' AND t.displayorder>='0' ORDER BY t.heats DESC ;rn+----+-------------+-------+-------+-----------------------+---------+---------+------+-------+-----------------------------+rn| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |rn+----+-------------+-------+-------+-----------------------+---------+---------+------+-------+-----------------------------+rn| 1 | SIMPLE | t | range | PRIMARY,heats,isgroup | PRIMARY | 3 | NULL | 21462 | Using where; Using filesort |rn+----+-------------+-------+-------+-----------------------+---------+---------+------+-------+-----------------------------+[/code]rn强制使用索引回复正常rn[code=sql]explain SELECT DISTINCT t.* FROM `pre_forum_thread` as t FORCE INDEX (PRIMARY) WHERE t.tid > 498405 AND t.readperm='0' AND t.tid NOT IN ('492187','513918') AND t.isgroup='0' AND t.dateline >= '1413771125' AND t.heats>'0' AND t.displayorder>='0' ORDER BY t.heats DESC limit 0,9 ;rn+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+rn| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |rn+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+rn| 1 | SIMPLE | t | range | PRIMARY | PRIMARY | 3 | NULL | 21462 | Using where; Using filesort |rn+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+[/code]rn表的主要几个索引rn PRIMARY KEY (`tid`),rn KEY `digest` (`digest`),rn KEY `sortid` (`sortid`),rn KEY `displayorder` (`fid`,`displayorder`,`lastpost`),rn KEY `typeid` (`fid`,`typeid`,`displayorder`,`lastpost`),rn KEY `recommends` (`recommends`),rn KEY `heats` (`heats`),rn KEY `authorid` (`authorid`),rn KEY `isgroup` (`isgroup`,`lastpost`),rn KEY `special` (`special`),rn KEY `fid_dateline_displayorder_heats` (`fid`,`displayorder`,`dateline`,`heats`)rnrn比较好奇的是为什么没有limit的时候使用的主键索引,加上limit之后会变成heats

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试