切忌 SELECT *，就算表只有一列

原文地址

尽量避免 SELECT *，即使在单列表上也是如此 – 如果你现在不同意这一点，读完这篇文章，你可能就要动摇了。

2012年的一个故事

这是我 12 年前（约 2012-2013 年）在客户后台应用程序中遇到的一个真实故事。

当时，后端 API 一直稳定运行，速度仅为个位数毫秒。但突然有一天，应用程序变得非常迟钝。

我们检查了提交，没发现明显的问题，大部分改动都是良性的。即使恢复了所有提交（有人会懂，作这样无意义的尝试，就说明走投无路了），程序仍然很慢，API 响应时间从原先的几毫秒暴增到 500 毫秒至 2 秒不等。

鉴于后台没有导致速度变慢的变更，我们检查了数据库查询，发现 3 个具有超大文件的 blob 字段，它们表上的 SELECT * 正在返回到后台应用程序。

原来，这个表只有两个整数列，API 运行 SELECT * 来返回并使用这两个字段。但后来管理员添加了三个 blob 字段，由另一个应用程序使用和填充。这些 blob 字段没有返回给客户端，后端 API 却需要拉取其他应用程序填充的额外字段，造成数据库、网络和协议序列化开销。

数据库读取如何进行

在行存储数据库引擎中，行以「页面」为单位存储。每页有一个固定的页眉，包含多条记录；每条记录有一个记录页眉，后面跟着各自的列。例如 PostgreSQL 中的示例：

在这里插入图片描述

当数据库获取一个页面并将其放入共享缓冲池，我们就可以访问该页面中的所有行和列。如果内存中所有列都是现成的，那么 SELECT * 真的又慢又费钱吗？如果是，为什么会这样？以下将展开探讨这些问题。

跟仅索引扫描说拜拜

使用 SELECT * 意味着数据库优化器不能选择只扫描索引。

例如，假设需要 90 分以上学生的 ID，而成绩列上有一个索引包含作为非键的学生 ID，这个索引就非常适合查询。

但是由于需要所有字段，数据库需要访问堆数据页来获取剩余字段，从而增加了随机读取次数，进而增加 I/O。相对地，不使用 SELECT *，数据库只需扫描成绩索引并返回 ID 即可。

反序列化成本

反序列化或解码是将原始字节转换为数据类型。这包括获取字节序列（通常来自文件、网络通信等），并将其转换回结构化更强的数据格式，如编程语言中的对象或变量。

执行 SELECT * 查询时，数据库需要反序列化所有列，即使是特定使用情况下可能不需要的列。这会增加计算开销，降低查询性能。只选择必要的列，可以降低反序列化成本，提高查询效率。

并非所有列都是内联的

SELECT * 查询的一个重要问题是，并非所有列都存储在页面内。文本或 blob 等大型列可能存储在外部表中，只有请求时才会检索（例如 Postgres TOAST 表）。这些列通常都经过压缩，因此在执行包含大量文本字段、几何数据或 blob 的 SELECT * 查询时，会给数据库带来额外负担，即从外部表中获取值、解压缩并将结果返回给客户端。