我听说在编写SQL命令时使用SELECT *通常是不好的做法，因为选择您特别需要的列会更有效。
如果我需要选择表中的每一列，我应该使用
SELECT * FROM TABLE
or
SELECT column1, colum2, column3, etc. FROM TABLE
在这种情况下，效率真的重要吗?如果你真的需要所有的数据，我认为SELECT *在内部会更优，但我这么说并没有真正理解数据库。
我很好奇在这种情况下最好的做法是什么。
更新:我可能应该指定，我真正想要执行SELECT *的唯一情况是，当我从一个表中选择数据时，我知道总是需要检索所有列，即使添加了新列。
然而，鉴于我所看到的反应，这似乎仍然是一个坏主意，由于我曾经考虑过的许多技术原因，SELECT *不应该被使用。
当前回答
为了补充其他人所说的，如果您选择的所有列都包含在一个索引中，则结果集将从索引中提取，而不是从SQL中查找其他数据。
其他回答
select *是一件坏事，有四个主要原因:
The most significant practical reason is that it forces the user to magically know the order in which columns will be returned. It's better to be explicit, which also protects you against the table changing, which segues nicely into... If a column name you're using changes, it's better to catch it early (at the point of the SQL call) rather than when you're trying to use the column that no longer exists (or has had its name changed, etc.) Listing the column names makes your code far more self-documented, and so probably more readable. If you're transferring over a network (or even if you aren't), columns you don't need are just waste.
我总是建议指定您需要的列，以防您的模式发生变化而不需要额外的列。
此外，用表名限定列名。当查询包含连接时，这很重要。如果没有表限定，就很难记住哪个列来自哪个表，并且向其他表之一添加类似名称的列可能会破坏查询。
如果你需要每一列，那么只需使用SELECT *，但记住，顺序可能会改变，所以当你消费的结果访问他们的名字，而不是通过索引。
我将忽略关于*需要如何获得列表的注释-解析和验证命名列的机会等于处理时间，如果不是更多的话。不要过早地优化;-)
明确地定义列，因为SQL Server将不需要对列进行查找来拉出它们。如果定义了列，则SQL可以跳过该步骤。
这将会被猛烈抨击，但我做了一个选择*，因为几乎所有的数据都是从SQL Server视图中检索的，这些视图将多个表中所需的值预组合到一个易于访问的视图中。
然后我想要所有的列从视图不会改变，当新字段添加到底层表。这有一个额外的好处，允许我改变数据的来源。视图中的FieldA一次可以被计算，然后我可以将其更改为静态。不管怎样，视图给我提供了FieldA。
它的美妙之处在于它允许我的数据层获得数据集。然后它将它们传递给我的BL，然后可以从它们创建对象。我的主应用程序只知道这些对象并与之交互。我甚至允许我的对象在传递数据箭头时自我创建。
当然，我是唯一的开发人员，所以这也有帮助:)
