UPDATE vs COUNT与SELECT性能

Question

此陈述是真还是假

这些查询的表现

SELECT * FROM table;

UPDATE table SET field = 1;

SELECT COUNT(*) FROM table;

相同

或者是否曾经存在一个人的表现与另一个人的表现大不相同的情况？

更新

1. 如果SELECT和UPDATE之间存在很大差异，我会更感兴趣。如果需要，可以忽略COUNT（*）
2. 假设select执行全表扫描。此更新还将对表中的所有行执行更新。
3. 假设更新只更新一个字段 - 虽然它会更新所有行（它是一个索引字段）
4. 我知道他们会花费不同的时间，他们会做不同的事情。我想知道的是，差异是否显着。例如。如果更新将比选择的时间长5倍，那么它很重要。使用此作为阈值。而且没有必要准确。只是给出一个近似值。

Answer 1

当你说“表现”时，你的意思是“执行它们需要多长时间”？

• 其中一个是返回所有行中的所有数据。
• 其中一个（如果删除“FROM”）是将数据写入行。
• 一个是计算行并且不返回行中的任何数据。

所有这三个查询都做了完全不同的事情。因此，可以合理地得出结论，所有这三个都需要不同的时间来完成。

最重要的是，你为什么问这个问题？你想解决什么？我有一种不好的感觉，你问这个问题，你走错了路。

Answer 2

涉及不同的资源类型：

• 磁盘I / O（这是每个DBMS中成本最高的部分）
• 缓冲压力：取一行将导致从磁盘中取出一个页面，这需要缓冲存储器存储在
中
• 中间表，结构和聚合的工作/暂存内存。
• ＆＃34;终端＆＃34; I / O到前端进程。
• 锁定，序列化和版本控制以及日记的成本
• CPU成本：在大多数情况下（与磁盘I / O相比），这是可以忽略的。

问题中的UPDATE查询最难：它会导致所有磁盘页面被提取，放入缓冲区，变成 new 缓冲区并写回磁盘。在正常情况下，它还会导致其他进程被锁定，因此会产生争用，甚至会产生缓冲压力。

SELECT *查询也需要所有页面;它需要将它们 all 转换/格式化为前端格式并将它们发送回前端。

SELECT COUNT(*)是所有资源中最便宜的。在最糟糕的情况下， all 必须提取磁盘页面。如果存在索引，则需要更少的磁盘I / O和缓冲区。 CPU成本仍然可以忽略（恕我直言）和＆＃34;终端＆＃34;输出是边际的。

Answer 3

我在这里有一个大的（授予索引的）表，这就是我找到的

从X中选择*（限制为前100,000条记录）（12.5秒）

从X中选择count（*）（返回数百万条记录）（15.57秒）

索引表的更新速度非常快（不到一秒）

Answer 4

所有三个查询都做了截然不同的事情。

它们各自都有自己的性能特征，无法直接比较。

你能澄清一下你试图调查的内容吗？

Answer 5

SELECT和UPDATE应该大致相同（但它们可能很容易变化，这取决于数据库）。 COUNT（*）在某个级别缓存在许多数据库中，因此查询可以很容易地为O（1）。当然，UPDATE的延迟实现也可能是O（1），但我不知道当前有人这样做。

tl; dr：“False”或“it depends”。