我听说在编写SQL命令时使用SELECT *通常是不好的做法,因为选择您特别需要的列会更有效。

如果我需要选择表中的每一列,我应该使用

SELECT * FROM TABLE

or

SELECT column1, colum2, column3, etc. FROM TABLE

在这种情况下,效率真的重要吗?如果你真的需要所有的数据,我认为SELECT *在内部会更优,但我这么说并没有真正理解数据库。

我很好奇在这种情况下最好的做法是什么。

更新:我可能应该指定,我真正想要执行SELECT *的唯一情况是,当我从一个表中选择数据时,我知道总是需要检索所有列,即使添加了新列。

然而,鉴于我所看到的反应,这似乎仍然是一个坏主意,由于我曾经考虑过的许多技术原因,SELECT *不应该被使用。


当前回答

这取决于您的DB服务器的版本,但现代版本的SQL可以以任何一种方式缓存该计划。我想说的是,不管你的数据访问代码有什么可维护性,你都要使用它。

其他回答

每次都定义你想要SELECT的列。没有理由不这样做,性能的提高是非常值得的。

他们不应该给“SELECT *”选项

我发现有些人似乎认为指定列要花费更长的时间。由于您可以将列列表从对象浏览器拖过来,因此在查询中指定列(如果您有很多列,并且需要花费一些时间将它们放在单独的行上)可能需要额外的一分钟时间。为什么人们认为这很耗时呢?

如果你需要每一列,那么只需使用SELECT *,但记住,顺序可能会改变,所以当你消费的结果访问他们的名字,而不是通过索引。

我将忽略关于*需要如何获得列表的注释-解析和验证命名列的机会等于处理时间,如果不是更多的话。不要过早地优化;-)

对于直接查询DB(例如通过sqlplus提示符或通过DB管理工具),选择*通常很好——它省去了写出所有列的麻烦。

另一方面,在应用程序代码中最好枚举列。这有几个好处:

代码更清晰 你将知道结果返回的顺序(这对你来说可能重要,也可能不重要)

“select *”的问题在于可能会带来您并不真正需要的数据。在实际的数据库查询期间,所选列并不会真正增加计算量。真正“繁重”的是将数据传输回客户端,任何您并不真正需要的列都只会浪费网络带宽,并增加等待查询返回的时间。

即使您确实使用了来自“select *…”的所有列,这也只是暂时的。如果将来您更改表/视图布局并添加更多列,您将开始在您的选择中引入这些列,即使您不需要它们。

“select *”语句不好的另一个地方是视图创建。如果您使用“select *”创建了一个视图,然后向表中添加列,则视图定义和返回的数据将不匹配,您需要重新编译视图以使它们再次工作。

我知道写一个“选择*”是诱人的,因为我真的不喜欢手动指定所有的字段在我的查询,但当你的系统开始发展,你会发现这是值得花额外的时间/精力在指定字段,而不是花更多的时间和精力消除错误在你的视图或优化你的应用程序。