我听说在编写SQL命令时使用SELECT *通常是不好的做法，因为选择您特别需要的列会更有效。
如果我需要选择表中的每一列，我应该使用
SELECT * FROM TABLE
or
SELECT column1, colum2, column3, etc. FROM TABLE
在这种情况下，效率真的重要吗?如果你真的需要所有的数据，我认为SELECT *在内部会更优，但我这么说并没有真正理解数据库。
我很好奇在这种情况下最好的做法是什么。
更新:我可能应该指定，我真正想要执行SELECT *的唯一情况是，当我从一个表中选择数据时，我知道总是需要检索所有列，即使添加了新列。
然而，鉴于我所看到的反应，这似乎仍然是一个坏主意，由于我曾经考虑过的许多技术原因，SELECT *不应该被使用。
当前回答
这取决于您的DB服务器的版本，但现代版本的SQL可以以任何一种方式缓存该计划。我想说的是，不管你的数据访问代码有什么可维护性，你都要使用它。
其他回答
即使查询不是通过网络发送，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').
当然，对于一个小而简单的系统来说，所有这些都不太重要。
选择特定列更好的一个原因是，它提高了SQL Server从索引访问数据的概率，而不是查询表数据。
这是我写的一篇关于它的文章:选择查询的真正原因是糟糕的索引覆盖
它也不太容易更改，因为任何消耗数据的代码都将获得相同的数据结构，而不管您将来对表模式做了什么更改。
如果你需要每一列，那么只需使用SELECT *，但记住，顺序可能会改变，所以当你消费的结果访问他们的名字，而不是通过索引。
我将忽略关于*需要如何获得列表的注释-解析和验证命名列的机会等于处理时间，如果不是更多的话。不要过早地优化;-)
让我们想想哪一个更快。如果你可以选择你需要的数据，那么速度会更快。然而，在测试中，您可以提取所有数据，以判断哪些数据可以根据业务需求过滤掉。
我发现有些人似乎认为指定列要花费更长的时间。由于您可以将列列表从对象浏览器拖过来，因此在查询中指定列(如果您有很多列，并且需要花费一些时间将它们放在单独的行上)可能需要额外的一分钟时间。为什么人们认为这很耗时呢?
