主页 / dba / 问题 / 72493
Accepted
dotancohen
Asked: 2014-07-28 03:11:26 +0800 CST

为什么 SELECT * 比 SELECT foo 快几个数量级？

  • 772

考虑一个值和哈希表，如下所示：

+------------+----------+------+-----+---------+----------------+
| Field      | Type     | Null | Key | Default | Extra          |
+------------+----------+------+-----+---------+----------------+
| id         | int(11)  | NO   | PRI | NULL    | auto_increment |
| val        | char(9)  | NO   |     | NULL    |                |
| val_hashed | char(50) | YES  |     | NULL    |                |
+------------+----------+------+-----+---------+----------------+

以下查询在 0.00 秒内完成：

SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;

但是，此查询需要 3 分 17 秒：

SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1;

我看到，当查询运行时，进程列表将其显示为 status Sorting result。这种情况是完全可以重现的。请注意，还有另一个进程INSERT连续对表执行操作。

为什么更具体的查询会比查询花费更长的时间来运行*？我一直认为，*出于性能原因，应该专门避免查询。

mysql performance

2 个回答

  1. Best Answer

    该短语ORDER BY 1指的是不同的列；在第一个它将是id，在第二个val。因为id它是键，所以它会被索引，而且order by工作量很小。但是，为了order by val，系统必须检索每一行，按 对整个表进行排序val，然后只选择其中一行。

    将两个查询都更改为order by id，我认为您的执行时间几乎相同。

    • 34

  2. MG 很好地解释了查询中的性能差异。我要解决这个问题：

    我一直认为，出于性能原因，应该专门避免 * 查询。

    select *本身没有特别的惩罚，滥用时会出现问题。在单表查询中它工作得很好。现在将该表连接到另一个具有 20 列的表，然后将连接添加到每个具有许多列的其他 5 个表。现在这是一个问题。那些在不解释原因的情况下教授广泛的创可贴“从不做X”的人也是如此。

    • 7

相关问题