为什么阿里巴巴禁用select *

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

引言

阿里巴巴开发手册中指出:
【强制】在表查询中,一律不要使用 * 作为查询的字段列表,需要哪些字段必须明确写明
说明:

  • 增加查询分析器解析成本
  • 增减字段容易与 resultMap 配置不一致
  • 无用字段增加网络 消耗,尤其是 text 类型的字段
    文章将从这几个方面展开说明

增加查询分析器解析成本

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

image.png

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 就知道要做什么了。在开始执行之前,还要先经过优化器的处理。优化器是在表里面有多个索引的时候,决定使用哪个索引,或者在一个语句有多表关联(join)的时候,决定各个表的连接顺序
  • MySQL通过分析器知道了要做什么,通过优化器知道了要怎么做,就进入了执行器阶段开始执行语句。开始执行的时候首先要判断一下是否有对表t的查询权限,如果没有就会返回没有权限的错误

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

image.png

前面已经提到查询到的中只是用到了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 *这样的SQL语句,虽然通常情况下即使真的写了这样的select *这样的SQL语句,对项目的影响可能也没这么大,但好习惯还是要养成的
我还是觉得之前写的文章也很不错,用户管理模块:如何保证用户数据安全,还是要再继续宣传一波,点个赞在走吧

image

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,602评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,442评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,878评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,306评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,330评论 5 373
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,071评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,382评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,006评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,512评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,965评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,094评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,732评论 4 323
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,283评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,286评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,512评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,536评论 2 354
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,828评论 2 345

推荐阅读更多精彩内容