- 如何优化sql带查询的分页查询
1、分析浅分页和深分页查询的效率(深分页的效率更差)
分析:
- 其中type为all说明走的全表扫描
- Extra说明有额外执行我们的using filesort
深分页
分析:
情况是一样的但是执行时间会有不同
浅分页1.2s
深分页2.0s
思考:为什么浅分页的查询时间短,而深分页查询时间长?
原理:其中浅分页我们的偏移量小,而我们的深分页偏移量大,其中偏移量大扫描的行数就会比浅分页要多,所以就时间更长
2、如何优化sql
2.1、方案一order by增加索引(我们要先给这个排序字段建立索引。这样不就走索引了吗)
分析
我们就发现其中key走了索引,然后type就是index了,extra也为空,那么也就是没有执行额外的任务了
我们再看深分页(出现问题了)
分析:还是全表扫描,也有额外执行任务,没走索引
浅分页用时,0.38s
深分页用时,1.91s
思考:为什么浅分页查询得到提升,深分页没有变化?
原理:
我们找完sorce是很快,但是我们找其他字段还会回表查找,而浅分页回表成本会很低,而深分页的回表成本会很高所以就不行了
2.2深分页强制走索引?(用时3.1s更高了)
用时更高了!!!
原理:我们的排序有时间成本,回表也有时间成本(mysql帮我们两者去最优反而没什么用了)
2.3、深分页回表成本高我们就不要回表,增加联合索引(给order by 和select增加联合索引)执行时间大大提高
其中key有走联合索引,extra 消除了using filesort也就是使用了我们的覆盖索引
!!!执行时间0.04s
2.4、不足之处
当我们需求变更的时候(例如又需要查找其他字段),索引就失效了
解决方案
2.4.1、方案1.我们根据id手动回表(让其强制走索引)
先找id,再根据id找其对应的三个参数
分析
用时0.08s
2.4.2、方案二:从业务着手,通过限制分页和前端配合交互(每页最后一条的所需数据字段传过来)
时间0.058s
原理:是我们的where条件和我们的desc配合,查询出分页。