If you name the columns in a SELECT statement, they will be returned in the order specified, and may thus safely be referenced by numerical index. If you use "SELECT *", you may end up receiving the columns in arbitrary sequence, and thus can only safely use the columns by name. Unless you know in advance what you'll be wanting to do with any new column that gets added to the database, the most probable correct action is to ignore it. If you're going to be ignoring any new columns that get added to the database, there is no benefit whatsoever to retrieving them.

即使您现在希望选择每一列，也可能不希望在某人添加一个或多个新列之后选择每一列。如果您使用SELECT *来编写查询，那么在某些时候，您可能会冒这样的风险，即有人可能会添加一列文本，从而使您的查询运行得更慢，即使您实际上并不需要该列。

如果您添加了想要的新列，这难道不意味着需要更改的代码更少吗?

如果您确实想要使用新列，那么无论如何您都必须对代码进行大量其他更改。你只保存，new_column -只有几个字符的输入。

一般来说，你必须匹配你的SELECT *…不同类型的数据结构。如果不指定结果到达的顺序，正确排列所有内容可能会很棘手(而且更模糊的字段更容易错过)。

通过这种方式，您可以出于各种原因向表中添加字段(甚至在表中间)，而不会破坏整个应用程序中的sql访问代码。

当您只需要几列时使用SELECT *意味着传输的数据比您需要的多得多。这增加了数据库上的处理，并增加了将数据获取到客户端的延迟。此外，它在加载时将使用更多内存，在某些情况下会使用更多内存，例如大型BLOB文件，这主要是关于效率。

然而，除此之外，在查看查询时更容易看到正在加载哪些列，而不必查找表中的内容。

是的，如果您确实添加了一个额外的列，它会更快，但在大多数情况下，您希望/需要使用查询更改代码以接受新列，并且有可能获得您不想要/期望的列会导致问题。例如，如果获取所有列，然后依赖循环中的顺序来分配变量，然后再添加一个，或者如果列的顺序发生了变化(从备份恢复时就发生过这种情况)，它可能会丢弃所有内容。

这也是为什么在执行INSERT操作时总是要指定列的原因。

这里有一个重要的区别，我认为大多数答案都忽略了。

SELECT *不是问题。返回SELECT *的结果是问题所在。

举个例子，在我看来:

WITH data_from_several_tables AS (
    SELECT * FROM table1_2020
        UNION ALL
    SELECT * FROM table1_2021
    ...
)
SELECT id, name, ...
FROM data_from_several_tables
WHERE ...
GROUP BY ...
...

这避免了大多数答案中提到的使用SELECT *的所有“问题”:

读取的数据比预期的多?现代数据库中的优化器会意识到实际上并不需要所有列 源表的列顺序会影响输出吗?我们仍然选择和 显式返回数据。 消费者不能看到他们从SQL?您所操作的列在代码中是显式的。 索引可能不被使用?同样，现代优化器应该处理这个问题，就像我们没有选择*一样

这里有一个可读性/可重构性的优势——不需要重复很长的列列表或其他常见的查询子句(如过滤器)。如果在使用SELECT *和SELECT <columns>(在绝大多数情况下-显然总是在关键情况下配置运行代码)时，查询计划有任何不同，我会感到惊讶。

在很多情况下，SELECT *会在应用程序的运行时导致错误，而不是在设计时。它隐藏了应用程序中列更改或坏引用的信息。