选择更少的SQL列是否会加快请求速度？

我有一个rails/backbone单页应用程序处理大量SQL查询

这是一项请求：

SELECT * FROM `posts` WHERE `thread_id` = 1

比这个快：

SELECT `id` FROM `posts` WHERE `thread_id` = 1

---

选择未使用的列对查询执行时间的影响有多大

将有两个组件：查询时间和I/O时间（您还可以将I/O分解为服务器I/O和服务器客户端（网络）I/O）

---

只选择一列在这两方面都会更快-当然是因为要获取和传输的数据更少，但也因为所讨论的列可能是用于查找数据的任何索引的一部分，因此，服务器可能不必查找实际的数据页—它可以直接从索引中提取数据。

选择较少的列通常会更快。不幸的是，很难说时差到底有多大。这可能取决于列的数量和其中包含的数据（例如，大CLOB的获取时间可能比简单整数长）、已设置的索引以及您与数据库服务器之间的网络延迟

---

对于时间差的确切答案，我能说的最好是同时进行两次查询，并查看每一次查询所需的时间。

对于所有实际目的，当查找一行时，差异可以忽略不计。随着结果行数的增加，差异可能会变得越来越重要，但只要您在thread_id上有一个索引，并且您不超过表中所有行的10-20%，这仍然不是一个大问题。仅供参考，差异系数来源于这样一个事实：选择

*

将强制对每一行在主索引中进行额外的查找。只需在

thread\u id

上查找辅助索引，即可满足仅选择

id

的要求

此外，任何大型字段（如BLOB文档或大型测试字段）都会带来明显的成本。如果

posts

字段的值为几十KBs，那么显然检索它们会增加额外的传输成本

所有这些都假设有一个正常的执行引擎，具有B树或ISAM行模式存储。几乎所有的“表格”和引擎都属于这一类。如果您谈论的是柱状存储，那么差异将非常显著，因为柱状存储只读取感兴趣的列，而读取额外的列会对此类存储引擎产生更明显的影响

---

在

thread\u id

上有或没有索引将产生非常明显的影响。确保您拥有它。

对于您的应用程序来说，性能差异几乎毫无疑问是微不足道的。尝试一下，看看你是否能发现不同；这很容易尝试。

速度较慢。更多数据必须从数据库传输到运行查询的应用程序。您是指同一复合索引中的

thread\u id

和

id

？可能，还是

thread\u id

上包含

s
id
的索引（取决于服务器软件）