CTO说了，谁在用select * 就走人！！
点击“终码一生”，关注，置顶公众号
每日技术干货，第一时间送达！
对于在 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：防止找不到本篇文章，可以收藏点赞，方便翻阅查找哦
往期推荐