您好, 欢迎来到 !    登录 | 注册 | | 设为首页 | 收藏本站

mysql force index 优化案例

bubuko 2022/1/25 19:59:08 mysql 字数 1917 阅读 652 来源 http://www.bubuko.com/infolist-5-1.html

1. ct_monitor 表记录200多万条记录 2. device 表 45 条记录 3. 两个表进行join并排序 需要?16.750 秒 我们一看,就知道这个结果 明显的 不符合常识!!! 如果我们 先查 ct_monitor 表的 主键 排序之后的 6条记录,然后用那6条记录来关联 dev ...

1. ct_monitor 表记录200多万条记录

技术分享图片

2. device 表 45 条记录

技术分享图片

3. 两个表进行join并排序 需要 16.750 秒

技术分享图片

我们一看,就知道这个结果 明显的 不符合常识!!!

如果我们 先查 ct_monitor 表的 主键 排序之后的 6条记录,然后用那6条记录来关联 device表,根本不可能需要16秒的时间!!!!

4. 如果去掉 order by mm.id desc 时,只需要 0.001 秒:

技术分享图片

 可以看到问题主要是 order by mm.id desc 导致了使用磁盘进行文件排序。而又因为 ct_monitor表记录有200多万,所以需要耗时很长。

5. 如果 把 inner join 改成 left join :

技术分享图片

又只需要0.001秒了。

可以看到这里 ct_monitor 作为了驱动表,只有 ct_monitor 表的主键 排序查询到了 6条记录,然后 在根据 ct_monitor.deviceId 来关联 device的主键。

到这里,我们可以想到可以使用 force index 来强制 ct_monitor 表走 主键索引:

技术分享图片

这样,我们强制 ct_monitor 表使用主键索引,先使用主键排序获取到6条记录之后,在用 ct_monitor.deviceId 去关联 device表的主键,这个结果才是符合我们想象的一个执行过程。

而不是:

技术分享图片 

而不是:使用 ct_monitor 表的 deviceId 来关联 device 的 id,然后对整个结果进行 排序,在取6条记录。因为这样无法使用 ct_monitor 的主键进行排序。

最后的优化方案是使用 force index (primary) 来强制使用 ct_monitor的主键索引。

mysql force index 优化案例

原文:https://www.cnblogs.com/digdeep/p/12663846.html


如果您也喜欢它,动动您的小指点个赞吧

除非注明,文章均由 laddyq.com 整理发布,欢迎转载。

转载请注明:
链接:http://laddyq.com
来源:laddyq.com
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


联系我
置顶