即使查询不是通过网络发送，SELECT *也是一种糟糕的做法。

Selecting more data than you need makes the query less efficient - the server has to read and transfer extra data, so it takes time and creates unnecessary load on the system (not only the network, as others mentioned, but also disk, CPU etc.). Additionally, the server is unable to optimize the query as well as it might (for example, use covering index for the query). After some time your table structure might change, so SELECT * will return a different set of columns. So, your application might get a dataset of unexpected structure and break somewhere downstream. Explicitly stating the columns guarantees that you either get a dataset of known structure, or get a clear error on the database level (like 'column not found').

当然，对于一个小而简单的系统来说，所有这些都不太重要。

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

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

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

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

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

您实际上应该只选择您需要的字段，并且只选择所需的数量，即。

SELECT Field1, Field2 FROM SomeTable WHERE --(constraints)

在数据库之外，动态查询有注入攻击和畸形数据的风险。通常使用存储过程或参数化查询来解决这个问题。而且(虽然不是真正的大问题)服务器必须在每次执行动态查询时生成一个执行计划。

这将会被猛烈抨击，但我做了一个选择*，因为几乎所有的数据都是从SQL Server视图中检索的，这些视图将多个表中所需的值预组合到一个易于访问的视图中。

然后我想要所有的列从视图不会改变，当新字段添加到底层表。这有一个额外的好处，允许我改变数据的来源。视图中的FieldA一次可以被计算，然后我可以将其更改为静态。不管怎样，视图给我提供了FieldA。

它的美妙之处在于它允许我的数据层获得数据集。然后它将它们传递给我的BL，然后可以从它们创建对象。我的主应用程序只知道这些对象并与之交互。我甚至允许我的对象在传递数据箭头时自我创建。

当然，我是唯一的开发人员，所以这也有帮助:)

为了补充其他人所说的，如果您选择的所有列都包含在一个索引中，则结果集将从索引中提取，而不是从SQL中查找其他数据。