考虑到您正在选择所有列的规范，此时没有什么不同。但是，要意识到数据库模式确实会发生变化。如果您使用SELECT *，您将获得添加到表中的任何新列，即使您的代码很可能不准备使用或显示这些新数据。这意味着您正在将系统暴露给意外的性能和功能更改。

你可能会认为这是一个很小的开销，但要意识到你不需要的列仍然必须是:

从数据库读取 通过网络发送 编组到流程中 (适用于adotype技术)保存在内存中的数据表中 忽略和丢弃/垃圾收集

第1项有许多隐藏的成本，包括消除一些潜在的覆盖索引，导致数据页负载(和服务器缓存抖动)，引发行/页/表锁，这些锁本来是可以避免的。

将此与指定列而不是*的潜在节省进行平衡，唯一潜在的节省是:

程序员不需要重新访问SQL来添加列 SQL的网络传输更小/更快 SQL Server查询解析/验证时间 SQL Server查询计划缓存

对于第1项，实际情况是，您将添加/更改代码以使用您可能添加的任何新列，因此这是徒劳的。

对于第2项，这种差异很少足以使您使用不同的数据包大小或网络数据包数量。如果SQL语句传输时间是主要问题，那么可能首先需要降低语句的速率。

对于第3项，没有任何节省，因为无论如何都必须展开*，这意味着无论如何都要咨询表的模式。实际上，列出列也会产生相同的成本，因为它们必须根据模式进行验证。换句话说，这完全是一笔勾销。

对于第4项，当您指定特定列时，您的查询计划缓存可能会变大，但只有当您处理不同的列集时(这不是您所指定的)。在这种情况下，您确实需要不同的缓存条目，因为您需要根据需要使用不同的计划。

因此，由于您指定问题的方式，这一切都归结为面对最终模式修改时的问题弹性。如果您正在将这个模式刻录到ROM(这种情况会发生)，那么*是完全可以接受的。

但是，我的一般指导原则是，您应该只选择您需要的列，这意味着有时看起来像是您在请求所有这些列，但是dba和模式演变意味着可能会出现一些可能会极大地影响查询的新列。

我的建议是你应该总是选择特定的列。记住，你会不断擅长你所做的事情，所以要养成正确做这件事的习惯。

如果您想知道为什么模式可以在不更改代码的情况下更改，可以考虑审计日志、有效/过期日期和dba系统地添加的其他类似内容，以解决遵从性问题。另一个幕后更改的来源是系统中其他地方或用户定义字段的性能反规范化。

如果你需要每一列，那么只需使用SELECT *，但记住，顺序可能会改变，所以当你消费的结果访问他们的名字，而不是通过索引。

我将忽略关于*需要如何获得列表的注释-解析和验证命名列的机会等于处理时间，如果不是更多的话。不要过早地优化;-)

让我们想想哪一个更快。如果你可以选择你需要的数据，那么速度会更快。然而，在测试中，您可以提取所有数据，以判断哪些数据可以根据业务需求过滤掉。

指定你需要的列总是更好的，如果你想一次，SQL不必每次查询都想着“wtf是*”。最重要的是，稍后有人可能会向表中添加您在查询中实际上不需要的列，在这种情况下，通过指定所有列会更好。

您应该只选择您需要的列。即使你需要所有的列，最好列出列名，这样sql server就不需要查询系统表中的列了。

此外，如果有人向表中添加列，应用程序可能会崩溃。您的程序也会得到它没有预料到的列，而且它可能不知道如何处理它们。

除此之外，如果表有一个二进制列，那么查询将更慢，并使用更多的网络资源。

我发现，如果其他开发人员可能会使用代码，或者数据库可能会更改，那么列出列名就特别重要，这样您就可以始终获得一致的数据。