Mysql 更新vs计数vs选择性能

这句话是真是假

这些查询的性能

SELECT * FROM table;

UPDATE table SET field = 1;

SELECT COUNT(*) FROM table;

相同

或者，是否曾经有过一种情况，其中一种表现会与另一种表现大不相同

更新

我更感兴趣的是，如果选择和更新之间有很大的差异。如果需要，可以忽略计数（*）

假设select执行全表扫描。更新还将对表中的所有行执行更新

假设更新只更新一个字段-尽管它将更新所有行（它是一个索引字段）

我知道他们会花不同的时间，做不同的事情。我想知道的是，差异是否显著。如果更新的时间比选择的时间长5倍，那么它是重要的。将此用作阈值。没有必要精确。只要给出一个近似值

---

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

---

tl；dr：“False”或“it dependence”。

这三个查询所做的事情截然不同

它们都有各自的性能特点，不能直接进行比较

你能澄清你想调查的是什么吗？

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

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

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

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

我的工作中有一个很大的（被授予索引的）表，这就是我发现的

从X中选择*（限于前100000条记录）（12.5秒）

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

---

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

涉及到不同的资源类型：

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

问题中的

UPDATE

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

SELECT*

查询也需要所有页面；它需要将它们全部转换/格式化为前端格式并发送回前端

---

SELECT COUNT（*）

是所有资源中最便宜的。在最坏的情况下，必须提取所有磁盘页。如果存在索引，则需要更少的磁盘I/O和缓冲区。CPU成本仍然是可忽略的（IMHO），并且“终端”输出是边际的。

您认为更新是否会比SELECT*大5倍？这取决于具体情况。涉及的每个资源都是最终公式中的一个维度。每个维度都需要一个权重因子才能得到一个

x=c*y

类型的公式。IOW:YMMV。对其他不相关的查询和进程（主要是WRT缓冲区、内存和锁）也有一定的影响，如果我限制更新会怎么样。这会大大减少所需的时间吗？例如，假设它将无限制地更新表中的所有500000行。将其限制为1（因此仅更新表中的1行）是否会减少执行查询所需的时间？可能的更新没有限制。没有订单，因为在更新时没有order BY子句。限制UPDATE语句的唯一方法是使用WHERE子句：

UPDATE personel SET salary=salary*1.5，其中性别='f'不是真的，我只是尝试了一下它的工作更新豚鼠设置某物=3限制1；只更新了第一行