为什么阿里巴巴禁用select *

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

引言

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

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

说明：

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

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

增加查询分析器解析成本

首先介绍一下MySQL基本架构，基本结构如下图：

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到主键索引中查询到所有数据，具体过程可看下图

前面已经提到查询到的中只是用到了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 *