我听说在编写SQL命令时使用SELECT *通常是不好的做法，因为选择您特别需要的列会更有效。
如果我需要选择表中的每一列，我应该使用
SELECT * FROM TABLE
or
SELECT column1, colum2, column3, etc. FROM TABLE
在这种情况下，效率真的重要吗?如果你真的需要所有的数据，我认为SELECT *在内部会更优，但我这么说并没有真正理解数据库。
我很好奇在这种情况下最好的做法是什么。
更新:我可能应该指定，我真正想要执行SELECT *的唯一情况是，当我从一个表中选择数据时，我知道总是需要检索所有列，即使添加了新列。
然而，鉴于我所看到的反应，这似乎仍然是一个坏主意，由于我曾经考虑过的许多技术原因，SELECT *不应该被使用。
当前回答
选择特定列更好的一个原因是，它提高了SQL Server从索引访问数据的概率，而不是查询表数据。
这是我写的一篇关于它的文章:选择查询的真正原因是糟糕的索引覆盖
它也不太容易更改，因为任何消耗数据的代码都将获得相同的数据结构，而不管您将来对表模式做了什么更改。
其他回答
您实际上应该只选择您需要的字段，并且只选择所需的数量，即。
SELECT Field1, Field2 FROM SomeTable WHERE --(constraints)
在数据库之外，动态查询有注入攻击和畸形数据的风险。通常使用存储过程或参数化查询来解决这个问题。而且(虽然不是真正的大问题)服务器必须在每次执行动态查询时生成一个执行计划。
为应用程序中期望获得的每一列命名还可以确保如果有人更改表，只要您的列仍然存在(以任何顺序)，应用程序就不会崩溃。
对服务器来说，指定列名肯定更快。但是,如果
性能不是大问题(例如，这是一个网站内容数据库，每个表中有数百行，可能是数千行，但不是数百万行);和 你的工作是使用公共框架创建许多小型的类似应用程序(例如面向公众的内容管理网站)，而不是创建一个复杂的一次性应用程序;和 灵活性很重要(为每个站点定制大量的db模式);
那么你最好坚持使用SELECT *。在我们的框架中，大量使用SELECT *允许我们将一个新的网站托管内容字段引入到一个表中，赋予它CMS的所有好处(版本控制、工作流/审批等)，同时只在几个点上修改代码，而不是几十个点。
我知道DB专家们会因此而恨我——请继续，投我反对票——但在我的世界里，开发人员的时间是稀缺的，而CPU周期是丰富的，所以我相应地调整我所节省的和浪费的。
明确地定义列，因为SQL Server将不需要对列进行查找来拉出它们。如果定义了列，则SQL可以跳过该步骤。
上面所有人说的，加上:
如果你正在努力编写可读性强、可维护的代码，可以这样做:
SELECT foo, bar FROM widgets;
立即可读并显示意图。如果你打了那个电话，你知道你会得到什么。如果widget只有foo和bar列，那么选择*意味着您仍然需要考虑返回什么，确认顺序映射正确等等。然而，如果widget有更多的列，但您只对foo和bar感兴趣，那么当您查询通配符，然后只使用返回的部分内容时，您的代码就会变得混乱。
