我听说在编写SQL命令时使用SELECT *通常是不好的做法，因为选择您特别需要的列会更有效。
如果我需要选择表中的每一列，我应该使用
SELECT * FROM TABLE
or
SELECT column1, colum2, column3, etc. FROM TABLE
在这种情况下，效率真的重要吗?如果你真的需要所有的数据，我认为SELECT *在内部会更优，但我这么说并没有真正理解数据库。
我很好奇在这种情况下最好的做法是什么。
更新:我可能应该指定，我真正想要执行SELECT *的唯一情况是，当我从一个表中选择数据时，我知道总是需要检索所有列，即使添加了新列。
然而，鉴于我所看到的反应，这似乎仍然是一个坏主意，由于我曾经考虑过的许多技术原因，SELECT *不应该被使用。
当前回答
到目前为止，这里回答了很多很好的理由，这里还有一个没有被提到的理由。
显式地命名列将帮助您进行后续的维护。在某些情况下，您将进行更改或排除故障，并发现自己在问“这个列到底用在哪里”。
如果显式列出了名称，那么通过所有存储过程、视图等查找对该列的每个引用就很简单了。只需为您的DB模式转储一个CREATE脚本，并在其中进行文本搜索。
其他回答
使用特定的字段名，这样如果有人更改了您的表，您就不会得到意想不到的结果。关于主题:在执行插入操作时始终指定字段名，这样如果稍后需要添加列，就不必在生产版本中同时修复程序和更改数据库。
明确地定义列，因为SQL Server将不需要对列进行查找来拉出它们。如果定义了列，则SQL可以跳过该步骤。
对服务器来说，指定列名肯定更快。但是,如果
性能不是大问题(例如，这是一个网站内容数据库，每个表中有数百行，可能是数千行，但不是数百万行);和 你的工作是使用公共框架创建许多小型的类似应用程序(例如面向公众的内容管理网站)，而不是创建一个复杂的一次性应用程序;和 灵活性很重要(为每个站点定制大量的db模式);
那么你最好坚持使用SELECT *。在我们的框架中，大量使用SELECT *允许我们将一个新的网站托管内容字段引入到一个表中，赋予它CMS的所有好处(版本控制、工作流/审批等)，同时只在几个点上修改代码，而不是几十个点。
我知道DB专家们会因此而恨我——请继续，投我反对票——但在我的世界里，开发人员的时间是稀缺的，而CPU周期是丰富的，所以我相应地调整我所节省的和浪费的。
在性能方面，具有特定列的SELECT可以更快(不需要读入所有数据)。如果您的查询确实使用了所有列，那么带显式参数的SELECT仍然是首选。任何速度差异基本上都是不明显的，并且接近恒定时间。总有一天你的模式会改变，这是预防由此产生问题的好保险。
我发现有些人似乎认为指定列要花费更长的时间。由于您可以将列列表从对象浏览器拖过来，因此在查询中指定列(如果您有很多列，并且需要花费一些时间将它们放在单独的行上)可能需要额外的一分钟时间。为什么人们认为这很耗时呢?
