我听说在编写SQL命令时使用SELECT *通常是不好的做法，因为选择您特别需要的列会更有效。
如果我需要选择表中的每一列，我应该使用
SELECT * FROM TABLE
or
SELECT column1, colum2, column3, etc. FROM TABLE
在这种情况下，效率真的重要吗?如果你真的需要所有的数据，我认为SELECT *在内部会更优，但我这么说并没有真正理解数据库。
我很好奇在这种情况下最好的做法是什么。
更新:我可能应该指定，我真正想要执行SELECT *的唯一情况是，当我从一个表中选择数据时，我知道总是需要检索所有列，即使添加了新列。
然而，鉴于我所看到的反应，这似乎仍然是一个坏主意，由于我曾经考虑过的许多技术原因，SELECT *不应该被使用。
当前回答
当且仅当需要获取所有字段的数据时，使用显式字段名并不比使用*更快。
你的客户端软件不应该依赖于返回字段的顺序，所以这也是毫无意义的。
而且有可能(尽管不太可能)需要使用*获取所有字段，因为您还不知道存在哪些字段(考虑非常动态的数据库结构)。
使用显式字段名的另一个缺点是，如果字段名很多而且很长，那么阅读代码和/或查询日志就会更加困难。
所以规则应该是:如果你需要所有的字段，使用*，如果你只需要一个子集，显式命名它们。
其他回答
您实际上应该只选择您需要的字段，并且只选择所需的数量，即。
SELECT Field1, Field2 FROM SomeTable WHERE --(constraints)
在数据库之外，动态查询有注入攻击和畸形数据的风险。通常使用存储过程或参数化查询来解决这个问题。而且(虽然不是真正的大问题)服务器必须在每次执行动态查询时生成一个执行计划。
明确地定义列，因为SQL Server将不需要对列进行查找来拉出它们。如果定义了列，则SQL可以跳过该步骤。
指定你需要的列总是更好的，如果你想一次，SQL不必每次查询都想着“wtf是*”。最重要的是，稍后有人可能会向表中添加您在查询中实际上不需要的列，在这种情况下，通过指定所有列会更好。
嘿，实际一点。在创建原型时使用select *，在实现和部署时选择特定的列。从执行计划的角度来看，两者在现代系统中是相对相同的。但是，选择特定的列会限制必须从磁盘检索、存储在内存中并通过网络发送的数据量。
最终，最好的计划是选择特定的列。
考虑到您正在选择所有列的规范，此时没有什么不同。但是，要意识到数据库模式确实会发生变化。如果您使用SELECT *，您将获得添加到表中的任何新列，即使您的代码很可能不准备使用或显示这些新数据。这意味着您正在将系统暴露给意外的性能和功能更改。
你可能会认为这是一个很小的开销，但要意识到你不需要的列仍然必须是:
从数据库读取 通过网络发送 编组到流程中 (适用于adotype技术)保存在内存中的数据表中 忽略和丢弃/垃圾收集
第1项有许多隐藏的成本，包括消除一些潜在的覆盖索引，导致数据页负载(和服务器缓存抖动)，引发行/页/表锁，这些锁本来是可以避免的。
将此与指定列而不是*的潜在节省进行平衡，唯一潜在的节省是:
程序员不需要重新访问SQL来添加列 SQL的网络传输更小/更快 SQL Server查询解析/验证时间 SQL Server查询计划缓存
对于第1项，实际情况是，您将添加/更改代码以使用您可能添加的任何新列，因此这是徒劳的。
对于第2项，这种差异很少足以使您使用不同的数据包大小或网络数据包数量。如果SQL语句传输时间是主要问题，那么可能首先需要降低语句的速率。
对于第3项，没有任何节省，因为无论如何都必须展开*，这意味着无论如何都要咨询表的模式。实际上，列出列也会产生相同的成本，因为它们必须根据模式进行验证。换句话说，这完全是一笔勾销。
对于第4项，当您指定特定列时，您的查询计划缓存可能会变大，但只有当您处理不同的列集时(这不是您所指定的)。在这种情况下，您确实需要不同的缓存条目，因为您需要根据需要使用不同的计划。
因此，由于您指定问题的方式，这一切都归结为面对最终模式修改时的问题弹性。如果您正在将这个模式刻录到ROM(这种情况会发生)，那么*是完全可以接受的。
但是，我的一般指导原则是，您应该只选择您需要的列，这意味着有时看起来像是您在请求所有这些列，但是dba和模式演变意味着可能会出现一些可能会极大地影响查询的新列。
我的建议是你应该总是选择特定的列。记住，你会不断擅长你所做的事情，所以要养成正确做这件事的习惯。
如果您想知道为什么模式可以在不更改代码的情况下更改，可以考虑审计日志、有效/过期日期和dba系统地添加的其他类似内容，以解决遵从性问题。另一个幕后更改的来源是系统中其他地方或用户定义字段的性能反规范化。
