未解决mysql分页性能问题深究
Posted 郭大侠
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了未解决mysql分页性能问题深究相关的知识,希望对你有一定的参考价值。
大佬们请教一个mysql问题:现在有一个数据分页的功能
【1】前提如下:
(1.1)数据量大概有2亿条左右
(1.2)2个查询条件,每页100条记录,不显示数据总量和总页数
(1.3)正常情况下都ok,因为每次就是 limit 100,又不显示数据总量和总页数
并且还使用了 id>上一次分页数据最大的ID 这种方法避免深度翻页的问题,效果比较理想,速度毫秒级
【2】SQL
select * from Log where filetype =‘文件类型‘ and observetime >= ‘开始时间‘ and observetime <= ‘结束时间‘ and id > 上页数据最大的id order by observetime desc LIMIT 100
id 为主键、递增,filetype 、observetime 都是正常的二级索引
【3】问题
问题前提:正常情况 between observetime 的命中行数非常大
(3.1)当所有条件正常,并查询结果集大于100的时候,limit 100正常,速度500ms
(3.2)当某一个条件值(比如filetype写个不存在的类型时)使得筛选结果集为空,则非常慢几十秒
(3.3)当筛选结果集不满足100时,则非常慢几十秒(比如按照时间+文件类型查询的结果只有1条记录,小于limit 100,也会很慢,几十秒都没结果 )
原理
如果符合条件的数据足够多,则limit100的过程就是,从符合条件的第一条数据开始往后查,当查够100条数据,则立刻返回。
如果符合条件的数据不够,则会从符合条件的第一条数据开始往后扫描,一条条的查,直到把整个表扫描完仍然不够100条,才会返回结果(不够100条)。
解决方案:
方案一:
查出满足条件的数据一共有多少条,按照条数处理,最后一个Limit的数量剩余满足条件的数量。
但是,如果查询条件没有索引,统计总共有多少条的将会是个慢查询。
方案二:
类似滑动窗口的方式,每次对id查询idStart+1000=idEnd范围内的符合条件的数据。凑够1000条的时候返回,但是业务实现就会更加复杂。
参考:
https://blog.csdn.net/u014440417/article/details/80352550
以上是关于未解决mysql分页性能问题深究的主要内容,如果未能解决你的问题,请参考以下文章
FragmentStatePagerAdapter视图分页器片段在重新创建活动后未显示
[未解决问题记录]python asyncio+aiohttp出现Exception ignored:RuntimeError('Event loop is closed')(代码片段