天下事有难易乎?为之,则难者亦易矣;不为,则易者亦难矣。

CTO说了,谁在用select * 就走人!!

往事如烟 372次浏览 0个评论

点击“终码一生”,关注,置顶公众号

每日技术干货,第一时间送达!



对于在 RDBMS 查询中使用 SELECT *,我们大多数人都不会三思而后行,但也许我们应该这样做。今天这篇文章讨论下为什么。



1

为什么不?


为什么呢?很多 SQL Server 和其他 RDBMS(关系数据库管理系统)的人建议永远不要使用,当我在演示中使用它并告诉我的与会者不要使用SELECT * 时,它已成为我演讲中的一个噱头。SELECT *


让我们来看看为什么不建议使用SELECT *,特别是在生产环境中。



2

查询系统表


当我们编写SELECT * FROM table时,数据库引擎必须进入系统表以读取列元数据以实现结果。在读取系统表时,这会产生很小但可衡量的性能影响。如果大量查询使用SELECT *,这可能会导致系统表上的明显锁定。



3

列顺序


SELECT *按创建顺序返回列。如果从过去的输出中假设特定顺序,这可能会导致意外,但是在应用程序升级和修改期间以不同的顺序创建了列,这可能是相当常见的。想象一个场景,其中一个或多个列被附加到末尾以避免重建整个表,但是在应用程序的全新安装中,这些列可能具有不同的顺序。因此,查询将以不同的SELECT *顺序返回列,具体取决于该表的创建和/或修改方式。



4

表现


我们真的需要所有的列吗?通过限制返回的列,我们可以更好地利用在查询执行时消耗更少内存空间的索引。这是迄今为止限制SELECT语句中的列的最佳理由。更少的内存意味着更少的存储读取、更少的 CPU 周期和更快的查询。由于大多数数据库都是通过网络访问的,这是我们可以避免的另一个主要性能瓶颈。



5

什么时候应该?


与所有最佳实践一样,规则也有例外,这就是为什么您经常会听到顾问说“视情况而定”的原因。


例如,如果我们的应用程序是一个数据库设计工具(如MySQL和MariaDB的phpMyAdmin),我们可能应该一直带回所有列,并利用行限制和缓存来确保应用程序只带回它需要的内容.


另一个(常见)异常是在开发和测试环境中,或者如果我们需要解决生产中的问题。有时使用SELECT *. 这些决定应基于我们可获得的最佳可用信息,并且仅在适当的情况下。


PS:防止找不到本篇文章,可以收藏点赞,方便翻阅查找哦


往期推荐



IDEA 与 VsCode

每日开源 | 一款基于 SpringBoot 开源社区系统,简单大方!

JDK 18 / Java 18 正式发布:九项 JDK 增强

强烈推荐,一键生成数据库文档的大利器!

4 种主流的 API 架构风格对比

5 款顶级 Docker GUI 工具!免费又好用



ITZOO版权所有丨如未注明 , 均为原创丨转载请注明来自IT乐园 ->CTO说了,谁在用select * 就走人!!
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址