我的问题很简单——属性更少的 SQL 查询成本更低吗?
示例:假设我们的users
表有 10 列,例如userId
, name
, phone
, email
, ...
SELECT name, phone FROM users WHERE userId='id'
比这个便宜
SELECT * FROM users WHERE userId='id'
从资源利用的角度来看是不是真的?
我的问题很简单——属性更少的 SQL 查询成本更低吗?
示例:假设我们的users
表有 10 列,例如userId
, name
, phone
, email
, ...
SELECT name, phone FROM users WHERE userId='id'
比这个便宜
SELECT * FROM users WHERE userId='id'
从资源利用的角度来看是不是真的?
这取决于。
限制投影中的列数当然可以提高性能,但这取决于可用的索引。如果我们假设它userId
是主键或至少是索引列,您会期望数据库的优化器通过使用具有userId
作为前导列的索引进行查找来确定要获取的行。
如果有一个索引,(user_id, phone)
或者如果phone
您的数据库支持该概念,则该索引上是否包含列,数据库可以phone
从它用于查找要返回的行的索引中获取。这样,数据库就不必访问实际的表来获取phone
. 包含数据库处理查询而不访问表所需的所有信息的索引称为“覆盖索引”。粗略地说,在索引中搜索要返回的行的成本可能与访问表以获取投影的其他列的成本大致相同。如果您可以限制投影中的列数以使用覆盖索引,则可能会显着降低查询成本。更重要的是,如果访问表以获取每一列涉及执行多次读取,因为 Oracle 中的链行或外联 LOB 列、PostgreSQL 中支持 TOAST 的数据类型等。
减少投影中的列数也将减少需要通过网络发送的数据量以及客户端处理该数据所需的内存量。当您有更大的字段时,这往往是最重要的。例如,如果表中的一列users
恰好是用户记录的 LDAP 路径,那么它的长度可能很容易达到数百个字符,并且占用了一半的网络带宽消耗和一半的中间层使用的内存。如果您正在构建一个需要为几百个用户提供服务的相对低流量的内部业务线应用程序,那么这些事情可能并不重要。如果您正在构建需要为数百万用户提供服务的大容量 SaaS 应用程序,这可能非常关键。
从宏观上看,两者都是微不足道的。如果数据按行存储,则没有太大区别,因为检索一行数据的成本并不高。也许如果其中一列特别大,那么避免对其进行检索将是有益的。
但是如果数据是按列存储的,那么第一个更便宜,因为每个条目都存储在不同的位置。