与指定要检索的列相比,从 SQL 表中选择所有列是否昂贵?
SELECT * FROM table
对比
SELECT col1, col2, col3 FROM table
知道我正在查询的某些表有超过 100 列可能会很有用。
可能是。这取决于表上定义了哪些索引。
如果有一个非聚集索引,col1,col2,col3
那么该索引可以用来满足查询(因为它比表本身更窄,无论是堆索引还是聚集索引),这应该会降低 I/O 成本。
通常,它也是首选的,这样您就可以确定哪些查询正在使用表中的特定列。
如果表没有索引,或者只有一个聚集索引,或者没有涵盖特定查询的索引,那么无论如何都必须访问堆/聚集索引的每一页。即使那样,如果您有任何行外数据(例如较大的varchar(max)
),那么如果您不包含该列,那么SELECT
您可以避免I/O 成本。
让我们把它分解成主要问题:
实际的数据库/应用程序:您键入查询的方式可能会改变 SQL 应用程序实际优化查询的方式、从何处获取数据等。再说一次,它可能不会。在这里很难一概而论,取决于数据库应用程序和设置。
程序员资源:使用 * 代替输入内容对您来说更容易、更快捷。耶!如果命令背后的“含义”字面意思是“获取所有内容”,那么使用 * 而不是手动列出所有列可能是程序员交流的好方法。当程序员事后阅读代码时,面对数百个列名的列表是一种不愉快的经历。另一方面,手动列出内容可以作为一个信号,表明您出于某种原因专门要求这些列。它不是一个强烈的信号,但它仍然是一个信号。
其他资源/IO/内存等:现在,如果您实际上并不需要所有 100 列并且您因为懒惰而查询它们,那么我们将进入更深的灰色区域。从什么数据库加载?查询结果去哪了?这些东西的读/写速度有多快?你真的想对所有列都这样做吗?执行查询将使用多少内存或资源?它会使用索引吗?它被索引了吗?在这个阶段你甚至需要关心优化吗?
所以总而言之,它是一个灰色地带……
在这种情况下,性能取决于查询中索引的正确使用。
如果您的数据库已正确规范化并且您在 where 子句中使用了索引,那么性能肯定会更好。
例如。
select * from tableName where id=232
这里使用索引。
您可以参考以下链接:
通常,您应该只选择查询所需的列。
有时,由于执行计划如何优化整个存储过程,选择稍后在存储过程中使用的查询的所有列不会产生任何影响。列上的索引也会产生影响。