我总是建议指定您需要的列，以防您的模式发生变化而不需要额外的列。

此外，用表名限定列名。当查询包含连接时，这很重要。如果没有表限定，就很难记住哪个列来自哪个表，并且向其他表之一添加类似名称的列可能会破坏查询。

在某些情况下，SELECT *适用于维护目的，但一般情况下应该避免使用。

These are special cases like views or stored procedures where you want changes in underlying tables to propagate without needing to go and change every view and stored proc which uses the table. Even then, this can cause problems itself, like in the case where you have two views which are joined. One underlying table changes and now the view is ambiguous because both tables have a column with the same name. (Note this can happen any time you don't qualify all your columns with table prefixes). Even with prefixes, if you have a construct like:

选择A.， B. -您可能会遇到客户端现在难以选择正确字段的问题。

一般来说，我不使用SELECT *，除非我在做一个有意识的设计决策，并指望相关的风险很低。

指定列列表通常是最好的选择，因为如果有人向表中添加/插入列，您的应用程序不会受到影响。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

为应用程序中期望获得的每一列命名还可以确保如果有人更改表，只要您的列仍然存在(以任何顺序)，应用程序就不会崩溃。

结果太大了。从SQL引擎生成结果并将结果发送到客户机的速度很慢。

客户端是一个通用的编程环境，不是也不应该被设计为过滤和处理结果(例如WHERE子句，ORDER子句)，因为行数可能非常大(例如数千万行)。