select * 的使用是否合理？

Question

我一直向我的开发人员宣讲 SELECT * 是邪恶的，应该像瘟疫一样避免。

有没有什么情况可以证明它是合理的？

我不是在谈论 COUNT(*) - 大多数优化器都可以弄清楚。

编辑

我说的是生产代码。

我看到的关于这种不良做法的一个很好的例子是一个遗留的 asp 应用程序，它在存储过程中使用 select * ，并使用 ADO 循环返回的记录，但得到了按索引列出的列。您可以想象当将新字段添加到字段列表末尾以外的其他位置时会发生什么。

Answer 1

我很高兴在审核触发器中使用 * 。

在这种情况下，它实际上可以证明是有好处的，因为它将确保如果将附加列添加到基表中，它将引发错误，因此不会忘记在审计触发器和/或审计表结构中处理此问题。

（就像dotjoe）我也很高兴在派生表中使用它列表表达式。尽管我习惯于反过来做。

WITH t
     AS (SELECT *,
                ROW_NUMBER() OVER (ORDER BY a) AS RN
         FROM   foo)
SELECT a,
       b,
       c,
       RN
FROM   t; 

我对 SQL Server 最熟悉，至少优化器可以毫无问题地认识到只需要列 a,b,c 以及在内表表达式不会导致检索和丢弃不需要的列的任何不必要的开销。

原则上，SELECT * 在视图中应该没问题，而且它是视图中的最终 SELECT，应该避免它，但在 SQL Server 中这可能会导致问题因为它存储视图的列元数据，当基础表更改时不会自动更新，并且使用 * 可能会导致混乱和不正确的结果，除非运行 sp_refreshview 来更新它元数据。

Answer 2

在很多场景下 SELECT * 是最优解决方案。在 Management Studio 中运行临时查询只是为了了解您正在使用的数据。查询您尚不知道列名的表，因为这是您第一次使用新架构。构建一次性快速工具来执行一次性迁移或数据导出。

我同意，在“正确的”开发中，您应该避免它 - 但在很多情况下，“正确的”开发不一定是业务问题的最佳解决方案。规则和最佳实践很棒，只要您知道何时打破它们。 :)

Answer 3

当使用 CTE 时，我将在生产中使用它。但是，在本例中，它并不是真正的 select *，因为我已经在 CTE 中指定了列。我只是不想在最终选择中重新指定。

with t as (
    select a, b, c from foo
)

select t.* from t;

Answer 4

如果您谈论的是实时代码，我想不到。

人们说这使得添加列更容易开发（因此它们会自动返回并且可以在不更改存储过程的情况下使用），但他们不知道如何编写最佳代码/sql。

我只在编写不会被重用的临时查询时使用它（找出表的结构，当我不确定列名是什么时获取一些数据）。

Answer 5

我认为在 exists 子句中使用 select * 是合适的：

select some_field from some_table 
where exists 
 (select * from related_table [join condition...])

有些人喜欢在这种情况下使用 select 1，但它并不优雅，而且它不会带来任何性能改进（早期优化再次出现）。

Answer 6

在生产代码中，我倾向于 100% 同意你的观点。

然而，我认为在执行即席查询时，* 不仅仅证明了它的存在。

Answer 7

你的问题已经得到了很多答案，但你似乎忽略了所有那些没有鹦鹉学舌地回应你想听到的内容的答案。不过，这是第三次（到目前为止）：有时没有瓶颈。有时，性能远胜于性能。有时，表在不断变化，修改每个 SELECT 查询只是需要管理的又一点可能的不一致。有时您必须按照不可能的时间表交付，这是您最不需要考虑的事情。

如果您生活在子弹时间中，当然，请输入所有列名称。但为什么要停在那里呢？在无模式 dbms 中重写您的应用程序。见鬼，用汇编语言编写您自己的 dbms。这真的会让他们看到。

Answer 8

请记住，如果您使用 select * 并且您有一个联接，则至少一个字段将被发送两次（联接字段）。这样无端浪费了数据库资源和网络资源。

Answer 9

作为一种工具，我使用它来快速刷新我的记忆，了解我可以从查询中返回什么。作为生产级别的查询本身..没办法。

Answer 10

我想，当创建处理数据库的应用程序（例如 phpmyadmin）时，并且您处于显示完整表格的页面中，在这种情况下使用 SELECT * 是合理的。

Answer 11

我唯一能想到的就是开发一个针对任何数据库运行的实用程序或 SQL 工具应用程序时。但即使在这里，我也倾向于查询系统表以获取表结构，然后从中构建任何必要的查询。

我的团队最近在一个地方使用了 SELECT * ，我认为这还可以......我们有一个数据库作为另一个数据库的外观而存在（称之为 DB_Data），所以它主要是由针对另一个数据库中的表的视图组成。当我们生成视图时，我们实际上生成了列列表，但是 DB_Data 数据库中有一组视图，它们是在将行添加到通用查找表时自动生成的（此设计在我到达这里之前就已就位）。我们编写了一个 DDL 触发器，以便当此过程在 DB_Data 中创建视图时，会在外观中自动创建另一个视图。由于生成的视图始终与 DB_Data 中的视图完全匹配，并且始终刷新并保持同步，因此为了简单起见，我们仅使用 SELECT * 。

如果大多数开发人员在其整个职业生涯中都没有在生产代码中合法使用 SELECT * ，我不会感到惊讶。

Answer 12

我使用 select * 来查询针对读取而优化的表（非规范化、平面数据）。非常有利，因为表格的目的只是支持应用程序中的各种视图。

Answer 13

phpmyadmin 的开发人员如何确保他们显示您的数据库表的所有字段？

Answer 14

可以想象，您希望设计数据库和应用程序，以便可以向表中添加列，而无需重写应用程序。如果您的应用程序至少检查列名称，则它可以安全地使用 SELECT * 并使用一些适当的默认操作处理其他列。当然，应用程序可以查询系统目录（或特定于应用程序的目录）以获取列信息，但在某些情况下，SELECT * 是执行此操作的语法糖。

然而，这样做存在明显的风险，并且向应用程序添加所需的逻辑以使其可靠很可能意味着在不太合适的介质中复制数据库的查询检查。我不会猜测现实生活中成本和收益如何权衡。

在实践中，我坚持使用 SELECT * 3 种情况（其他答案中提到了一些：

• 作为临时查询，在 SQL GUI 或命令行中输入。
• 作为 EXISTS 的内容 谓词
• 在处理通用表而无需知道它们的含义（例如转储器或差异）的应用程序中。

Answer 15

是的，但仅在意图实际从表中获取所有列而不是因为您想要表当前拥有的所有列的情况下。

例如，在我开发的一个系统中，我们有 UDF（用户定义字段），用户可以在报告中选择他们想要的字段、顺序以及过滤。构建结果集时，从我正在构建的临时表中简单地“选择 *”更有意义，而不必跟踪哪些列处于活动状态。

Answer 16

1. 我有几次需要显示列名未知的表中的数据。因此，我执行了SELECT * 并在运行时获取了列名称。

2. 我收到了一个旧版应用程序，其中一个表有 200 列，一个视图有 300 列。SELECT * 带来的风险并不比显式列出所有 300 列更糟糕。

Answer 17

取决于生产软件的上下文。

如果您正在为表管理工具编写一个简单的数据访问层，其中用户将选择表并在网格中查看结果，那么 *SELECT ** 似乎没问题。

换句话说，如果您选择通过其他方式处理“字段选择”（如检索结果集后在自动或用户指定的过滤器中），那么看起来就很好。

另一方面，如果我们谈论的是某种具有业务规则、定义的模式等的企业软件……那么我同意 *SELECT ** 是一个坏主意。

编辑：哦，当源表是触发器或视图的存储过程时，“*SELECT **”应该没问题，因为您通过其他方式（视图的定义或存储过程的结果集）管理结果集。

Answer 18

在生产代码中 Select * 在任何时候都是合理的：

• 它不是性能瓶颈
• 开发时间至关重要

为什么我需要返回并不得不担心更改相关存储过程的开销，每个我该在表中添加一个字段吗？

为什么我什至要考虑我是否选择了正确的领域，而绝大多数时候我无论如何都想要其中的大部分，而绝大多数时候我不想要，其他的东西是瓶颈吗？

如果我有一个特定的性能问题，那么我会回去修复它。否则，在我的环境中，这只是我可以不做的过早（且昂贵）的优化。

---

编辑..在讨论之后，我想我会补充一点：

...以及人们没有做过其他不良事情的地方，例如尝试访问列（i），无论如何，这可能会在其他情况下中断:)

Answer 19

我知道我参加聚会已经很晚了，但我会补充说，只要我知道我总是想要所有列，无论列名称如何，我都会使用 select * 。这可能是一个相当边缘的情况，但在数据仓库中，我可能想从第 3 方应用程序暂存整个表。我的标准流程是删除临时表并运行

select * 
into staging.aTable 
from remotedb.dbo.aTable

是的，如果远程表上的架构发生更改，下游依赖项可能会引发错误，但无论如何都会发生这种情况。

Answer 20

如果您想查找所有列并希望顺序，您可以执行以下操作（至少如果您使用 MySQL）：

SHOW COLUMNS FROM mytable FROM mydb; (1)

您可以看到有关的所有相关信息你所有的领域。您可以防止类型问题，并且可以确定所有列名称。这个命令非常快，因为你只要求表的结构。从结果中，您将选择所有名称并构建一个如下所示的字符串：

"select " + fieldNames[0] + ", fieldNames[1]" + ", fieldNames[2] from mytable". (2)

如果您不想运行两个单独的 MySQL 命令，因为 MySQL 命令很昂贵，您可以将 (1) 和 (2) 包含到存储过程中它将结果作为 OUT 参数，这样您只需调用存储过程，并且每个命令和数据生成都将在数据库服务器上发生。