赞
踩
order by col limit N,OFFSET M
MySQL 执行此类SQL时:先扫描到N行,再取 M行。
N越大,MySQL需扫描更多数据定位到具体的N行,这会耗费大量的I/O成本和时间成本。
为什么上面的SQL写法扫描数据会慢?
符合kid=3 and type=1 的记录有很多行,我们取第 9,10行。
select * from t where kid =3 and type=1 order by id desc 8,2;
对于Innodb,根据 idx_kid_type
二级索引里面包含的主键去查找对应行。
对百万千万级记录,索引大小可能和数据大小相差无几,cache在内存中的索引数量有限,而且二级索引和数据叶子节点不在同一物理块存储,二级索引与主键的相对无序映射关系,也会带来大量随机I/O请求,N越大越需遍历大量索引页和数据叶,需要耗费的时间就越久。
由于上面大分页查询耗时长,是否真的有必要完全遍历“无效数据”?
若需要:
limit 8,2
跳过前面8行无关数据页的遍历,可直接通过索引定位到第9、10行,这样是不是更快?
这就是延迟关联的核心思想:通过使用覆盖索引查询返回需要的主键,再根据主键关联原表获得需要的数据,而非通过二级索引获取主键再通过主键遍历数据页。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。