对于在 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 *. 这些决定应基于我们可获得的最佳可用信息,并且仅在适当的情况下。