UPDATE vs COUNT vs 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 中成本最高的部分）
• 缓冲压力：取一行会导致从磁盘取一页，这需要缓冲内存来存储
• 中间表、结构和聚合的工作/临时内存。
• 前端进程的“终端”I/O。
• 锁定、序列化、版本控制和日志记录的成本
• CPU 成本：在大多数情况下这是可以忽略的（与磁盘 I/O 相比）

问题中的UPDATE查询是最难的：它将导致该表的所有磁盘页面被提取、放入缓冲区、更改为新缓冲区并写回磁盘。在正常情况下，它还会导致其他进程被锁定，从而产生争用甚至更大的缓冲压力。

该SELECT *查询需要的所有网页，也; 它需要将它们全部转换/格式化为前端格式并将它们发送回前端。

SELECT COUNT(*)在所有资源上，这是最便宜的。在最坏的情况下，必须获取所有磁盘页面。如果存在索引，则需要较少的磁盘 I/O 和缓冲区。CPU 成本仍然可以忽略（恕我直言），“终端”输出是微不足道的。