select * 效率低的原因

原创 已于 2023-02-16 14:45:04 修改 · 1k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#sql #数据库

于 2023-02-16 13:48:35 首次发布
使用SELECT*可能导致服务器解析性能下降、增加IO读写消耗和网络传输成本。此外，它可能阻碍索引的利用，影响查询效率。对于索引，文章指出聚集索引存储所有行信息，而辅助索引存储列信息。并非所有列都适合创建索引，尤其是数据量小、不常用或频繁修改的列。

首先这是一条SQL查询语句，sql语句都是从客户端发给服务端的，select * 就会引发一些问题

1.解析sql性能慢，增加的服务器解析sql的成本

2.增加了IO读写的消耗，包括了不用的数据，甚至是大文本数据，用*作为条件会查询出大量不需要的数据

3.增加了网络传输的损耗

4.真正使用Java操作数据的时候，使用的resultset,resultsetmatadate不一致

5.如果使用*会屏蔽索引的使用，借助不到索引，性能自然也就会慢

 索引

聚集索引：记录表格全部行信息，每个表中只有一个

辅助索引：存储的是列信息-----引用

索引并不是越多越好的，表格中数据量较小，列不经常被利用当作条件，列经常用（频繁的修改）的时候不建议创建索引，索引本身是有空间和存储消耗的

select 某些字段比select * 更快
Top5软件工程硕士，先后在京东、字节从事多年Java后端开发、实时和离线大数据开发
05-21 5119
1尽量养成不要使用*的习惯，select * 可能会对性能产生严重影响, 有一种索引，叫做覆盖索引。准确来说它不是一种索引方式，而是一种索引覆盖查询列程度。比如有一个常用查询，只需要用到表中的某两列，user_id和post_id，而且有一个多列索引已经覆盖了这两个列，那么这个索引就是这个查询的覆盖索引了。如果select `user_id`,`post_id` from xxx 的话，mysq...
select* from table的弊端
IT修真院：初学者转行到互联网的聚集地
05-23 4619
这里是修真院后端小课堂，每篇分享文从 【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】 八个方面深度解析后端知识/技能，本篇分享的是： 【select* from table的弊端 】 大家好，我是IT修真院上海分院，一枚正直纯洁善良的如刚入门的Java程序员，今天试着给大家分享一下Select*from table的弊端 sql执行流...
为什么大家都说SELECT * 效率低
热门推荐
陈哈哈的菜园子
06-15 1万+
无论在工作还是面试中，关于SQL中不要用“SELECT *”，都是大家听烂了的问题，虽说听烂了，但普遍理解还是在很浅的层面，并没有多少人去追根究底，探究其原理。 废话不多说，本文带你深入了解一下"SELECT * "效率低的原因及场景。 本文很干！请自备茶水，没时间看记得先收藏 -- 来自一位被技术经理毒打多年的程序员的忠告
为什么SELECT * 效率低
上海市市花的博客
04-06 4248
为什么SELECT * 效率低一、效率低的原因1. 不需要的列会增加数据传输时间和网络开销2. 对于无用的大字段，如 varchar、blob、text，会增加 io 操作3. 失去MySQL优化器“覆盖索引”策略优化的可能性二、索引1. 联合索引优势：1. 减少开销2. 覆盖索引3. 效率高建立索引注意事项： 一、效率低的原因 增加查询分析器解析成本。 增减字段容易与 resultMap 配置不一致。 无用字段增加网络 消耗，尤其是 text 类型的字段。 1. 不需要的列会增加数据传输时间和网络开销
不懂就问：为什么SELECT * 会导致查询效率低？
欢迎关注公众号：【码农突围】，回复9999，可以获取一份LeetCode刷题笔记
12-03 450
点击上方“码农突围”，马上关注这里是码农充电第一站，回复“666”，获取一份专属大礼包真爱，请设置“星标”或点个“在看”作者：陈哈哈，转载自：https://blog.youkuaiyun.com/...
Mysql 索引【总结】
单枪匹码
09-18 422
一、索引：索引时数据库中提高查询效率的技术，类似于字典的目录； 1、为什么使用索引？ 如果不使用索引，数据会零散的保存在每一个磁盘块当中，查询数据时，需要挨个的遍历每一个磁盘块查找数据，如果数据量非常大，遍历每一块数据也是一件非常耗时的事情，添加索引后，会将磁盘块以树状结构进行保存，查询数据时会有目的性的访问部分磁盘块，因为访问的磁盘块数量降低，所以能够起到提高查询效率的作用； 2、索引是越多越好吗？ 不是，因为索引会占磁盘空间，通过某个字段创建的索引可能永远用不上，则这个索引完全没有存在的意义，只需要对查
为什么大家都说 SELECT * 效率低
MarkerHub的博客
07-23 171
小Hub领读：用什么字段，就select什么字段，养成好习惯！作者：陈哈哈blog.youkuaiyun.com/qq_39390545/article/details/106766965面试官：“...
MySQL的金科玉律：“不要使用SELECT *”
wdjnb的博客
05-10 1536
“不要使用SELECT *”几乎已经成为了MySQL使用的一条金科玉律，就连《阿里Java开发手册》也明确表示不得使用*作为查询的字段列表，更是让这条规则拥有了权威的加持。 不过我在开发过程中直接使用SELECT *还是比较多的，原因有两个： 因为简单，开发效率非常高，而且如果后期频繁添加或修改字段，SQL语句也不需要改变； 我认为过早优化是个不好的习惯，除非在一开始就能确定你最终实际需要的字段是什么，并为之建立恰当的索引；否则，我选择遇到麻烦的时候再对SQL进行优化，当然前提是这个麻...
MySQL优化之如何查找SQL效率低的原因
09-10
通过分析这些执行计划，我们可以发现SQL语句执行效率低下的具体原因。EXPLAIN命令会显示出查询的类型、哪些索引被使用、表是如何连接的、每一行数据如何被扫描等等。当执行EXPLAIN命令时，MySQL会返回一行或多行数据...
为什么大家都说 SELECT * 效率低
hello world！
07-01 414
点击上方“java大数据修炼之道”，选择“设为星标”优质文章, 第一时间送达作者：陈哈哈来源：blog.youkuaiyun.com/qq_39390545/article/details/1067...
为什么 SELECT * 效率低?
rockywish的博客
07-01 395
面试官：“小陈，说一下你常用的SQL优化方式吧。” 程序猿小一：“那很多啊，比如不要用SELECT *，查询效率低。巴拉巴拉…” 面试官：“为什么不要用SELECT * ？它在哪些情况下效率低呢？” 程序猿小一：“SELECT * 它好像比写指定列名多一次全表查询吧，还多查了一些无用的字段。” 面试官：“嗯…” 程序猿小一：“emmm~ 没了” 程序猿小一：“…??（几个意思）” 面试官：“嗯…好，那你还有什么要问我的么？” 程序猿小一：“我问你个锤子，把老子简历还我！ 无论在工作还是面试中，关于SQL.
面试官又问我Select * 为什么效率低下？
冢狐的私人空间
09-01 2135
Select * 为什么效率低下 ​ 无论是在平时的工作中还是面试中，都会遇到不让用Select *的情况，那么到底是什么原因导致其沦落到人人喊打的地步呢/ 效率低下的原因 ​ 在阿里java开发手册中关于Mysql的部分描述中提到：在表查询中一律不要使用* 作为查询的字段列表，需要用那些字段必须明确写明。原因如下： 增加查询分析器解析的成本 增减字符容易与resultMap配置不一致 无用字段增加网络消耗，尤其是test类型的字段 那么接下来我们就逐条深入的分析一下 不需要的列会增加数据传
SQL 查询优化：为何 SELECT * 会拖慢你的数据库速度
Lion_Long的博客
07-01 7520
在数据库查询中，SELECT * 语句虽然方便快捷，但却可能带来严重的性能问题。由于它会检索所有列和行数据，导致系统资源的浪费和查询效率的下降。此外，过多的数据传输也会增加网络负担，进一步影响系统性能。本文将探讨 SELECT * 带来的具体问题，并提供优化查询效率的方法。通过选择显式字段和合理使用索引，您可以显著提升数据库的性能和响应速度。
面试官：到底是什么原因才导致 select * 效率低下的?
xmt1139057136的专栏
02-08 860
你知道的越多，不知道的就越多，业余的像一棵小草！你来，我们一起精进！你不来，我和你的竞争对手一起精进！编辑：业余草blog.youkuaiyun.com/qq_39390545/article/det...
SELECT * 效率为什么低
a214704的博客
07-13 338
https://mp.weixin.qq.com/s?__biz=MzI2OTQ4OTQ1NQ==&mid=2247490328&idx=1&sn=e3b93d3542aeba029cfd74b353194c48&chksm=eadedf58dda9564ed7bda5101eaf483d420fabf8350c84cd9ac45a4c6364a415949612e4b130&xtrack=1&scene=90&subscene=93&sess
为什么大家都说SELECT * 效率低？
qq_37190771的博客
07-14 203
效率低的原因 先看一下最新《阿里java开发手册（泰山版）》中 MySQL 部分描述： 4 - 1. **【强制】**在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。说明： 增加查询分析器解析成本。 增减字段容易与 resultMap 配置不一致。 无用字段增加网络 消耗，尤其是 text 类型的字段。 开发手册中比较概括的提到了几点原因，让我们深入一些看看： 1 不需要的列会增加数据传输时间和网络开销 用“SELECT * ”数据库需要解析更多的对象、字段、权限、属性等相
为什么SELECT * 查询效率低
铭记：
06-25 551
看着你满怀期待的脸 不经意间 冲破了我对你的平淡 心头一酸 内心又有点波澜 这是否存在隐患 还是暗示某种惨淡 关于MYSQL语句优化的问题，老生常谈，什么尽量避免使用SELECT * ，尽量避免条件使用or，加上limit限制行数… 就在上周，公司的一个项目，功能是在发布文章时不发布保存草稿后，打开草稿重新发布时，地区的name不显示的BUG，主管让我排查了代码，原来是在写sql语句时没有对地区name的字段进行查询。 这时候我勤劳的优点就展现出来了，把那几个字段加上就好了，虽然脑海里浮现出了一个小星星.
select * 和select所有字段比效率高很多吗
最新发布
07-17
在SQL查询中，使用`SELECT *`和明确指定字段（如`SELECT column1, column2`）之间的效率差异是一个常见的性能优化问题。虽然在某些情况下它们的执行计划可能相同，但通常来说，选择具体字段可以带来更好的性能表现。 ### 查询效率差异的原因 1. **数据传输量** 当使用`SELECT *`时，数据库会返回表中的所有列，而不仅仅是用户需要的数据。这意味着更多的数据需要从磁盘读取、通过网络传输到客户端，并占用更多的内存资源[^4]。相比之下，指定字段可以减少不必要的数据传输，提高查询响应速度。 2. **索引利用情况** 如果查询只需要某些列，并且这些列已经被一个覆盖索引来包含，则数据库可以直接从索引中获取数据，而不必访问实际的数据行（即所谓的“覆盖索引”）。这种情况下的性能提升非常显著。然而，如果使用`SELECT *`，则很可能无法利用覆盖索引，因为查询涉及了所有列，而这些列不一定全部包含在一个索引中[^2]。 3. **锁定与并发控制** `SELECT *`可能会导致更长的锁持有时间，因为它涉及更多数据页或行的访问。这会影响并发性能，尤其是在高并发环境下。 4. **维护开销** 在设计视图或存储过程中使用`SELECT *`可能导致未来表结构变更时出现意外行为。例如，新增一列后，原本只期望得到几列的应用程序现在会接收到额外的数据，这可能引发逻辑错误或者需要额外处理[^1]。 5. **统计信息与执行计划稳定性** 明确列出所需字段有助于优化器生成更加稳定和准确的执行计划。此外，在某些数据库系统中，对于特定列的统计信息更新频率更高，这也影响着查询优化器的选择。 ### 实际测试案例 为了验证上述理论，可以通过对比两种方式在相同环境下的执行时间来观察差异。以下是一个简单的Spark SQL示例，展示如何进行这样的比较： ```python # 使用 SELECT * start_time = time.time() spark.sql("SELECT * FROM src WHERE key < 10").collect() end_time = time.time() print(f"SELECT * took {end_time - start_time} seconds") # 使用指定字段 start_time = time.time() spark.sql("SELECT key, value FROM src WHERE key < 10").collect() end_time = time.time() print(f"SELECT specific columns took {end_time - start_time} seconds") ``` 此代码片段展示了如何测量两种不同查询语句的执行时间。实际结果将取决于具体的数据库配置、表大小以及硬件性能等因素。 ### 结论 尽管`SELECT *`提供了便利性，但在生产环境中推荐始终明确列出所需的字段。这样做不仅可以提高查询性能，还能增强应用程序的可维护性和健壮性。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值