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

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

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

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

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

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

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

使用列名进行选择提高了数据库引擎从索引访问数据的可能性，而不是查询表数据。

当数据库模式发生变化时，SELECT *使您的系统暴露在意想不到的性能和功能变化中，因为您要将任何新列添加到表中，即使您的代码还没有准备好使用或显示这些新数据。

引用自这篇文章。

永远不要用“SELECT *”，

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

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

我不认为这真的可以有一个通用的规则。在许多情况下，我避免使用SELECT *，但我也使用过SELECT *非常有用的数据框架。

和所有事情一样，有收益也有成本。我认为收益与成本的等式的一部分是你对数据结构有多少控制。在SELECT *工作良好的情况下，数据结构受到严格控制(它是零售软件)，因此没有太大的风险，有人会将一个巨大的BLOB字段发送到表中。