前往顾页
以后地位: 主页 > 收集编程 > .Net实例教程 >

SQL查询中回表对机能的影响

时候:2018-03-05 11:56来源:知行网www.zhixing123.cn 编辑:麦田守望者

运营反应某个服从速率很慢,查了一下,定位到以下 SQL:

select id from user
where name like ‘%foobar%’
order by created_at limit 10;

业务需求,LIKE 的时候必须利用恍惚查询,我当然晓得这会导致全表扫描,不过速率确切太慢了,直观感受,全表扫描不至于这么慢!

 

我利用的数据库是 PostgreSQL,不过它和 MySQL 差不多,也能够 EXPLAIN:

SQL查询中回表对性能的影响
 

 

SQL With LIMIT

如上所示:先遵循 created_at 索引排序,再 filter 适合前提的数据,最后 limit 前往成果,看上去很完美,不过为甚么慢呢?出于经历主义,我去失落了 limit 再履行:

select id from user
where name like ‘%foobar%’
order by created_at;

果不其然,速率快了好几倍,再看看对应的 EXPLAIN:

SQL查询中回表对性能的影响
 

 

SQL Without LIMIT

如上所示:去失落 limit 后,底子就没用上索引,直接全表扫描,不过反而更快。

为甚么呢?要想搞清楚启事,你需求了解本例中 SQL 查询的措置流程:当利用 limit 时,因为只是前往几条数据,所以优化器感觉采取一个满足 order by 的索引比较划算;当不利用 limit 时,因为要前往所有满足前提的数据,所以优化器感觉不如直接全表扫描。不过就算晓得这些还是不足以解释为甚么在本例中全表扫描反而快,实际上这是因为当利用索引的时候,除非利用了 covering index,不然一旦索引定位到数据地点后,这里会有一个「回表」的操纵,形象一点来讲,就是前往原始表中对应行的数据,以便引擎进行再次过滤(比如本例中的 like 运算),一旦回表操纵过于频繁,那么机能无疑将急剧降落,全表扫描没有这个问题,因为它就没用索引,所以不存在所谓「回表」操纵。

我应当解释清楚了吧,别的,前面提到了 covering index,有兴趣的本身查吧。

顶一下
(1)
100%
踩一下
(0)
0%
------分开线----------------------------
标签(Tag):SQL查询 回表对机能
------分开线----------------------------
颁发评论
请自发遵循互联网相关的政策法规,严禁公布色情、暴力、革命的谈吐。
评价:
神色:
考证码:点击我更换图片
猜你感兴趣