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

还有一个更实际的原因:钱。当你使用云数据库时，你必须为数据处理付费，没有任何解释来读取你将立即丢弃的数据。

例如:BigQuery:

查询价格 查询定价是指运行SQL命令和用户定义函数的成本。BigQuery根据一个指标对查询收费:处理的字节数。

和控制投影-避免选择*:

最佳实践:控制投影—只查询所需的列。 投影指的是查询读取的列数。投影多余的列会导致额外的(浪费的)I/O和物化(写入结果)。 使用SELECT *是最昂贵的查询数据的方法。当您使用SELECT *时，BigQuery会对表中的每一列进行全面扫描。

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

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

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

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

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 *”，

我发现使用“SELECT *”的原因只有一个。

如有特殊要求和创建动态环境时添加或删除列，由应用程序代码自动处理。在这种特殊情况下，您不需要更改应用程序和数据库代码，这将自动影响生产环境。在这种情况下，您可以使用“SELECT *”。

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

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