为什么阿里巴巴禁用select *

最近写作生涯遭遇了滑铁卢,写了两篇文章阅读量都不怎么样,但还是要继续分享所学,服务端的菜鸡不能输,要重新称霸中原,233333当然这是很难的,后端优秀作者实在太多了,还得继续加油。回归主题,最近又在重新学习MySQL,想起了阿里开发手册禁用select * 查询语句,这是为什么呢

引言

阿里巴巴开发手册中指出:

【强制】在表查询中,一律不要使用 * 作为查询的字段列表,需要哪些字段必须明确写明

说明:

  • 增加查询分析器解析成本
  • 增减字段容易与 resultMap 配置不一致
  • 无用字段增加网络 消耗,尤其是 text 类型的字段

文章将从这几个方面展开说明

增加查询分析器解析成本

首先介绍一下MySQL基本架构,基本结构如下图:

为什么阿里巴巴禁用select *_第1张图片

MySQL 基本架构可以分为 Server 层和存储引擎层两部分。Server 层包括连接器、查询缓存、分析器、优化器、执行器等。存储引擎层负责数据的存储和提取,其架构模式是插件式的,支持 InnoDB、MyISAM、Memory 等多个存储引擎

当我们执行一条查询语句:select * from t where id = 1,在MySQL中执行过程如下:

  • 在真正执行select * from t where id = 1时首先需要输入命令mysql -uroot -p,通过连接器将客户端和服务层建立起连接
  • 建立起连接以后输入select * from t where id = 1这条SQL
  • 首先查找查询缓存中是否已经执行过该条语句
  • 若未命中查询缓存,则执行select * from t where id = 1这条SQL,分析器会对这条SQL进行词法分析。
  • MySQL 从输入的select这个关键字识别出来这是一个查询语句。
  • 把字符串t识别成表名t,把字符串id识别成列id
  • 判断输入的这个 SQL 语句是否满足 MySQL 语法

如果使用select 来查询语句,分析器需要进行额外的解析,如果直接指定成列名,则不需要进行额外的解析,直接识别成列名

失去MySQL优化器“覆盖索引”策略优化的可能性

假设有一条sql语句为select * from t where name = "何甜甜",其中id为主键,name为索引,而实际上这么写的目的只是想查询指定name的id

在innodb存储引擎中,索引可以分为非主键索引和主键索引,主键索引和主键的区别在于叶子节点存放数据的不同。主键索引中叶子节点存放的是整行数据,而非主键索引中叶子节点存放的是主键的值。现在我们来看select * from t where name = "何甜甜"这条语句是如何执行的

因为name是索引且name是查询条件,查询优化器会选择使用name索引。首先根据name查询到该name对应的主键id为1,因为需要查询的是指定name的所有数据,因此还需要根据主键id进行一次回表操作。所谓回表操作是指非主键索引中查询到主键id,在根据主键id到主键索引中查询到所有数据,具体过程可看下图

为什么阿里巴巴禁用select *_第2张图片

前面已经提到查询到的中只是用到了id字段,如果将原来的sql语句修改为select id from t where name = "何甜甜",就可以避免一次回表操作。在非主键索引中已经覆盖了查询需求【即所需查询的ID已在非主键索引上了】,也被称为覆盖索引。通过覆盖索引可以减少回表次数,从而显著提升查询性能,因此在实际写sql过程中应该尽量避免写select 这样的查询语句,写之前先反问是否真的需要用到这么多字段

增加IO操作

BLOB和TEXT是为了存储很大的数据而设计的字符串数据类型,当BLOB和TEXT值太大时,InnoDB会使用专门的外部存储区域来进行存储,每个值在行内需要1~4字节存储一个指针,然后在外部存储区域存储实际的值,如果查询的中有BLOB或TEXT类型的字段,则查询的BLOB或TEXT列需要在进行额外一次IO操作去外部存储区域将数据查询到,所以尽量避免使用select

增加数据传输时间和网络开销

传输数据过多会增加网络开销。同时,查询语句执行时会先将查询到的数据放到查询缓存区中,再从查询缓存中将结果返回给客户端,如果查询到的数据量非常大则需要花很多时间来存储结果,所以在说一次,避免使用select *

为什么阿里巴巴禁用select *_第3张图片

你可能感兴趣的