Hi ! 我是小小,今天带来本周的第三篇。为什么大家都在说 Select * 效率低。

面试现场

面试官:“小小啊,说一说你常用的SQL优化方式吧”。
小小:“很多的,相当多,比如不要用SELECT,查询效率低,巴拉巴拉。。。”
面试官: “为什么不要用 SELECT* ? 它在那些情况下效率低呢?”
小小: “SELECT * 它好像比写指定列多一次全表查询吧,还多查了一些无用的字段。”
面试官: “嗯?”
小小: “emememem~ 没了”
小小: “…??????”
面试官: “嗯,你还有什么药问的”
小小:“没了,我问你个锤子,赶紧把简历给我”
下面开始进入正题,

不需要的列会增加数据传输时间和网络开销

用SELECT * 数据库需要解析更多的对象,字段,权限,属性等等相关内容,在SQL语句复杂,硬解析较多的情况下,会对数据库造成沉重的负担。
增大网络开销,* 有时会误操作,带上log,icomMD%等之类的无用且大的文本字段,数据传输size会几何的增长,如果DB和应用程序不在同一台机器,这种开销相当的明显
即使 Mysql 服务器和客户端在同一台机器上,使用的协议还是 tcp,通信也需要额外的时间。

对无用的大字段,例如varchar,blob,text会增加io操作

正确来说,长度操作728字节的时候,会先把超出的数据序列化到另外一个地方,因此肚脐去的时候,这条记录会增加一次io操作。

失去Mysql优化器,覆盖索引优化措施的可能性

SELECT * 杜绝了覆盖索引的可能性,而基于 MySQL 优化器的“覆盖索引”策略又是速度极快,效率极高,业界极为推荐的查询优化方式。

例如,有一个表为 t(a,b,c,d,e,f),其中,a 为主键,b 列有索引。

那么,在磁盘上有两棵 B+ 树,即聚集索引和辅助索引(包括单列索引、联合索引),分别保存(a,b,c,d,e,f)和(a,b)。

如果查询条件中 where 条件可以通过 b 列的索引过滤掉一部分记录,查询就会先走辅助索引;如果用户只需要 a 列和 b 列的数据,直接通过辅助索引就可以知道用户查询的数据。

如果用户使用 SELECT *,获取了不需要的数据,则首先通过辅助索引过滤数据,然后再通过聚集索引获取所有的列,这就多了一次 B+ 树查询,速度必然会慢很多。

MySql | 为什么大家都在说 Select * 效率低插图

由于辅助索引的数据比聚集索引少很多,很多情况下,通过辅助索引进行覆盖索引(通过索引就能获取用户需要的所有列),都不需要读磁盘,直接从内存取。

而聚集索引很可能数据在磁盘(外存)中(取决于 buffer pool 的大小和命中率),这种情况下,一个是内存读,一个是磁盘读,速度差异就很显著了,几乎是数量级的差异。

后期维护

使用 SELECT * 时候,不熟悉代码库的人将会被迫查询文档,以了解能够进行有效更改之前需要返回那些列,从长远来看,使得代码更不具有可读性,从而耗费了更多的时间和精力。

如果代码取决于列顺序,SELECT * 则如果表的列顺序已经更改,则会隐藏等待发生的错误。

使用时配置更加复杂化。

设计模式

select * 是反设计模式。
查询的目的不太明显,应用程序使用的列是不透明的,打破的列的模块化设计。

关于作者

我是小小,一个生于二线,活在一线的程序猿,我是小小,我们下期再见。