选择*-为什么或为什么不？

Question

这两个查询之间真的有什么区别吗？

SELECT TOP 1000 [COL_1], [COL_2], [...], [COL_n] FROM [database].[schema].[table]

SELECT TOP 1000 * FROM [database].[schema].[table]

显然，如果我编写这样的代码，将来会产生问题，但是如果我真的需要查看我的临时SSMS查询窗口中的所有列，这有关系吗？我试着比较查询计划，但没有发现两者之间的区别。

编辑:让N的S匹配，因为SELECT 1对SELECT 1000不是这个问题的重点。此外，建议员额还简短地提到了使用SELECT *：

我只在特殊的报废查询中使用它，通常是在学习对象的架构时使用。

但是这个问题集中在持久的代码上。我的问题的范围仅限于不超过当前SSMS会话的临时声明。

Answer 1

在我的临时SSMS查询窗口中，这有关系吗？

在这种情况下--不，这不重要。但是，不使用SELECT *是一个很好的习惯，它可以减少懒散地将这些查询复制到指定用于生产的代码中的诱惑。

为了避免疑问:虽然通过SSMS或类似工具进行快速检查/诊断是完全可以接受的，但出于其他地方详细说明的原因，您应该尽可能在生产代码中避免使用SELECT *。

这表明了“SELECT *在SSMS中很好”的一个重要例外:如果您正在试验TSQL，而这最终会在其他地方的代码中永久化，那么无论如何您都需要使用非SELECT *版本进行测试，因为您可能遇到了一种边缘情况，使两者之间产生了意外的计划/性能差异，所以您最好在没有SELECT *的情况下开始工作，而不是以后为自己做更多的工作。

我试着比较查询计划，但没有发现两者之间的区别。

如果您选择了所有的列，那么SELECT *将展开到相同的查询中，所以计划总是相同的。

Answer 2

嗯，除了顶部查询将返回1000行而底部只返回1(我假设这不是您的问题)之外，不，在大多数正常情况下，我不会看到两者之间的性能或查询计划差异，特别是对于您所描述的即席SSMS查询。

最明显的例外是，您实际上并不需要所有的列；如果您只选择了几个特定的列，那么不仅可以检索更少的数据，而且SQL可以根据实际使用的内容做出更好的查询计划选择，并可能使用更高效的索引。

但是，在生产应用程序代码和存储过程中，我肯定会避开SELECT *，主要是出于性能以外的原因：

• 当从表中添加或删除列时，使用SELECT *的查询可能中断。
• 使用SELECT *的查询正在对将返回的列顺序进行假设。
• 正如评论中所提到的那样，UNION语句特别容易受到列号或顺序更改的影响。