Mysql优化技巧之Limit查询的优化分析
前言
在实际业务中对于分页来说是一个比较常见的业务需求。那么就会使用到limit查询，当我们在使用Limit查询的时候，在数据比较小、或者只查询前面一部分数据的时候效率是很高的。但是当数据量大的时候，或者查询offset数量比较大的时候，如：limit100000,20效率往往就不尽人意了。通常的一个办法就是Limit配合orderby，如果orderby有对用户的索引的话，效率通常是比较不错的。
对于这种情况，最简单的查询就是使用覆盖索引，查询某些需要的列。这样的效果是很好的
如下面这个
mysql>SELECT*FROMstudentLIMIT1000000,1; +---------+------------+------------+------------+-------+---------------------+ |id|first_name|last_name|created_at|score|updated_at| +---------+------------+------------+------------+-------+---------------------+ |1000001|kF9DxBgnUi|yLXnPSHJpH|2019-07-11|97|2019-07-1114:29:59|| +---------+------------+------------+------------+-------+---------------------+ 1rowsinset(0.31sec)
可以看到时间
mysql>EXPLAINSELECTscore,first_nameFROMstudentORDERBYcreated_atLIMIT1000000,20\G ***************************1.row*************************** id:1 select_type:SIMPLE table:student partitions:NULL type:index possible_keys:NULL key:time_sorce_name key_len:69 ref:NULL rows:1000001 filtered:100.00 Extra:Usingindex 1rowinset,1warning(0.00sec) mysql>
这样的话查询的列使用到的了覆盖索引，扫描行数会减少很多，但是这样的效果也不是很尽人意，但是如果有其他的查询的话，这样的查询也会变的很慢。
比如我们加上last_name列。
如下
mysql>SELECTscore,first_name,last_nameFROMstudentORDERBYcreated_atLIMIT1000000,1; +-------+------------+------------+ |score|first_name|last_name| +-------+------------+------------+ |86|knKsV2g2fY|WB5qJeLZuk| +-------+------------+------------+ 1rowinset(4.81sec) mysql>
这个查询需要执行4秒多的时间。通过分析可以看到这个查询是没有办法使用索引的
mysql>explainSELECTscore,first_name,last_nameFROMstudentORDERBYcreated_atLIMIT1000000,1\G ***************************1.row*************************** id:1 select_type:SIMPLE table:student partitions:NULL type:ALL possible_keys:NULL key:NULL key_len:NULL ref:NULL rows:6489221 filtered:100.00 Extra:Usingfilesort 1rowinset,1warning(0.00sec) mysql>
那么我们现在把查询修改如下
mysql>SELECTstudent.score,student.first_nameFROMstudentINNERJOIN(SELECTidFROMstudentORDERBYcreated_atLIMIT1000000,1)AStempUSING(id); +-------+------------+ |score|first_name| +-------+------------+ |15|2QWZ| +-------+------------+ 1rowinset(0.18sec)
mysql>EXPLAINSELECTstudent.score,student.first_name,last_nameFROMstudentINNERJOIN(SELECTidFROMstudentORDERBYcreated_atLIMIT1000000,1)AStempUSING(id); +----+-------------+------------+------------+--------+---------------+-----------------+---------+---------+---------+----------+-------------+ |id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows|filtered|Extra| +----+-------------+------------+------------+--------+---------------+-----------------+---------+---------+---------+----------+-------------+ |1|PRIMARY||NULL|ALL|NULL|NULL|NULL|NULL|1000001|100.00|NULL| |1|PRIMARY|student|NULL|eq_ref|PRIMARY|PRIMARY|4|temp.id|1|100.00|NULL| |2|DERIVED|student|NULL|index|NULL|time_sorce_name|69|NULL|1000001|100.00|Usingindex| +----+-------------+------------+------------+--------+---------------+-----------------+---------+---------+---------+----------+-------------+ 3rowsinset,1warning(0.00sec)
分析结果,可以看到这个时候只查询了1000001一条数据记录。为什么会有这样的变化呢。这种叫延时关联，先通过使用覆盖索引查询返回需要的主键,再根据主键关联原表获得需要的数据，尽可能的减少了需要扫描的行数。
在某些特定的场合，其实有另外一种优化方案的。比如要获取最新的几条插入记录。那么在上一次查询的时候我们可以记录下最后一条记录的主键ID(last_id)。
那么查询就可以改为
SELECTscore,first_name,last_name,idFROMstudentWHEREid>=last_idORDERBYidASCLIMIT1
比如last_id=1000000那么这个查询就会从1000000开始。这样的场景不管数据到多大的offset性能都会很好。
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。