问题是：select * 和 select column 的差别出现的原因以及解决方法。

原因：

1. 数据库的存储结构是基于I/O页面的，每个I/O页面通常是8KB。每次读取或写入数据都是以页面为单位进行的，无法跨越多个页面。

2. 特殊情况下，如Blob数据类型或某些优化策略，数据可能存储在多个页面中，但通常情况下，数据仍需存储在单个I/O页面中。

解决方法：

除了在Exists或Not Exists的子查询中使用Select *之外，应该始终通过指定列名来选择需要的列。

文章如下：

在关系数据库管理系统中，使用select语句可以从表中检索数据。然而，对于select语句中选择所有列（select *）和选择特定列（select column）之间存在差别。select * 和 select column 这个问题的出现原因和解决方法。

数据库的存储结构是以I/O页面为基础的，每个I/O页面通常是8KB。每次读取或写入数据都是以页面为单位进行的，无法跨越多个页面。因此，每行数据必须始终存储在一个且仅一个页面中，不能跨越多个页面。特殊情况下，如Blob数据类型或某些优化策略，数据可能存储在多个页面中，但通常情况下，数据仍需存储在单个I/O页面中。

由于这种底层结构的限制，每次检索数据都会读取整个行的数据，无论是否选择了所有列。因为每次I/O操作都是以页面为单位进行的，无法只读取所需的列。所以，从性能的角度来看，select * 和 select column 没有差别。但是，基于其他原因，我们应该始终通过指定列名来选择需要的列。

除了在Exists或Not Exists的子查询中使用Select *之外，我们应该始终通过指定列名来选择需要的列。在这些特殊情况下，虽然数据可能存储在多个页面中，但仍然需要将包含指针的列存储在单个I/O页面中。

总之，尽管在某些特殊情况下可能存在一些例外，但通常情况下，我们应该始终通过指定列名来选择需要的列，而不是使用select *。这样可以避免潜在的维护和逻辑错误，并且不会对性能造成影响。

参考资料：

- [Why is SELECT * considered harmful?](https://stackoverflow.com/questions/3639861)

在生产代码中永远不要使用SELECT *是因为以下几个原因：

1. 当你不给数据库任何提示时，它首先需要检查表的定义以确定该表的列。这个查找会花费一些时间，虽然单个查询中的时间不多，但随着时间的推移会累积起来。

2. 如果你只需要表的2/3列，那么你选择了多余的1/3数据，这些数据需要从磁盘检索并通过网络传输。

3. 如果你开始依赖于数据的某些方面，例如返回的列的顺序，一旦表重新组织并添加了新列（或删除了现有列），你可能会遇到令人讨厌的意外。

4. 在SQL Server中（不确定其他数据库），如果你需要一部分列，非聚集索引可能会覆盖该请求（包含所有所需的列）。使用SELECT *，你从一开始就放弃了这种可能性。在这种特殊情况下，数据将从索引页中检索（如果它们包含所有必要的列），因此与执行SELECT *....查询相比，磁盘I/O和内存开销要小得多。

是的，最初需要多输入一些（像SQL Server的工具SQL Prompt甚至可以帮助你），但这是一个规则没有任何例外的案例：在生产代码中永远不要使用SELECT *。永远不要。

关于第二点，我只关心内存和I/O开销。你提到的第二点意味着选择操作不会拉取原子元组，而是只从磁盘中拉取所需的列。所以在select column中，会有一个内存开销来检查要拉取哪个单元格的数据。据我所知，数据始终以元组的形式存储在磁盘上。不确定select是如何拉取的，所以select *不需要对表的数据结构进行全面检查。

尽管在实践中我同意你的观点，在从表中获取列数据的所有情况下，你对"EVER"的强调使我指出这个规则并不适用于所有SQL查询...具体而言，在存在谓词之后的子查询中使用（如Where Exists (Select * From ...），使用Select *肯定没有问题，在某些领域中甚至被认为是最佳实践。

Bretana: 是的，IF EXISTS(SELECT *...是一个特殊情况-在这种情况下，实际上并没有检索任何数据，只是检查是否存在特定的行，所以SELECT *在这里不是一个问题...

通常，如果我们需要一致地访问表的特定部分，我们会创建一个只包含我们需要的列的视图。当然，然后我们会从my_view中选择所有列。从性能的角度来看，这和从表中选择所有列一样糟糕吗？

另一方面，在PostgreSQL中，如果你选择所有列，你会得到一个可以实际使用的良好格式的数据类型，而不是无法直接传递给其他存储过程的通用记录。

如果我正在开发一个API，可以从我的表中检索数据。既然我不知道用户对哪些数据感兴趣，那么使用SELECT *是否可以接受？

: 我仍然会反对这种做法-假设你的表中有一些"管理"数据，你不想向客户暴露。我会始终明确地指定要获取的列的列表。

对于专门用于API的视图查询，怎么样？

_s SELECT column1 FROM (SELECT * FROM table1).这种写法也被认为是不好的吗？

: 是的-在生产/专业代码环境中，你应该始终避免使用SELECT *-可能除了IF EXISTS (SELECT * FROM ... WHERE ....)这种情况-在这种情况下，*不会有问题，因为实际上并没有检索任何数据，而只是检查是否存在与WHERE子句匹配的特定行。

在编写SQL查询语句时，应该始终只选择实际需要的列。选择较少的列而不是较多的列从来不会降低效率，并且也会遇到较少的意外副作用，比如通过索引在客户端访问结果列，然后在表中添加新列后这些索引变得不正确。

在访问结果列时，使用数字索引的情况是否常见？如果使用ORM，则通常使用字符串键或属性名称访问列数据。

很久以前，有一个初级程序员从一个表中选择了所有列，并对列的顺序做出了假设；一旦有人更改了表，他的所有代码都会崩溃。我们当时真是开心啊。

一般来说，使用列的顺序来编写代码可能是一个坏主意，因为这样可读性会变差。更糟糕的是，使用SELECT *来选择所有列。

哇，通过在客户端代码中使用索引访问列似乎是一个极其糟糕的主意。对我来说，以任何方式依赖结果集中列的顺序都感觉非常不合适。