选择特定列更好的一个原因是，它提高了SQL Server从索引访问数据的概率，而不是查询表数据。

这是我写的一篇关于它的文章:选择查询的真正原因是糟糕的索引覆盖

它也不太容易更改，因为任何消耗数据的代码都将获得相同的数据结构，而不管您将来对表模式做了什么更改。

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

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

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

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

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

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

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

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

当且仅当需要获取所有字段的数据时，使用显式字段名并不比使用*更快。

你的客户端软件不应该依赖于返回字段的顺序，所以这也是毫无意义的。

而且有可能(尽管不太可能)需要使用*获取所有字段，因为您还不知道存在哪些字段(考虑非常动态的数据库结构)。

使用显式字段名的另一个缺点是，如果字段名很多而且很长，那么阅读代码和/或查询日志就会更加困难。

所以规则应该是:如果你需要所有的字段，使用*，如果你只需要一个子集，显式命名它们。

明确地定义列，因为SQL Server将不需要对列进行查找来拉出它们。如果定义了列，则SQL可以跳过该步骤。