为什么 SELECT * 效率低?

本文探讨了在SQL查询中避免使用SELECT *的原因,解释了它导致的数据传输时间增加、网络开销、IO操作增多以及失去覆盖索引优化的机会。详细分析了覆盖索引的工作原理和联合索引的优势,强调了正确选择索引列的重要性。
摘要由CSDN通过智能技术生成

面试官:“小程,说一下你常用的SQL优化方式吧。”
程序猿小一:“那很多啊,比如不要用SELECT *,查询效率低。巴拉巴拉…”
面试官:“为什么不要用SELECT * ?它在哪些情况下效率低呢?”
程序猿小一:“SELECT * 它好像比写指定列名多一次全表查询吧,还多查了一些无用的字段。”
面试官:“嗯…”
程序猿小一:“emmm~ 没了”
程序猿小一:“…??(几个意思)”
面试官:“嗯…好,那你还有什么要问我的么?”
程序猿小一:“我问你个锤子,把老子简历还我!

无论在工作还是面试中,关于SQL中不要用“SELECT *”,都是大家听烂了的问题,虽说听烂了,但普遍理解还是在很浅的层面,并没有多少人去追根究底,探究其原理。
废话不多说,本文带你深入了解一下"SELECT * "效率低的原因及场景。

一、效率低的原因

先看一下最新《阿里java开发手册(泰山版)》中 MySQL 部分描述:

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

增加查询分析器解析成本。
增减字段容易与 resultMap 配置不一致。
无用字段增加网络 消耗,尤其是 text 类型的字段。
开发手册中比较概括的提到了几点原因,让我们深入一些看看:

1. 不

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值