mysql - MySQL 更新查询中观察到突然下降

Question

我已经分析了 MySQL 更新查询的性能。在稳定状态之后，在吞吐量图中观察到突然下降。我已经重做了几次测试。我发现，对于同一个场景，突然下降的地方并不是同一个点。它随时间而变化。我想知道这是因为缓冲池中的缓存而发生的？我使用 MsSQL 做了相同的测试，但我找不到这个问题。请帮助我解决这个困惑。

Answer 1

性能(对于大表)完全取决于磁盘命中率。以及缓解这种情况的技巧。

需要更多详细信息 - 例如 SHOW CREATE TABLE、SHOW TABLE STATUS 和 UPDATE。性能下降有多严重？ buffer_pool 有多大？它占RAM的几分之几呢？但这里有一些一般性答案。

“更改缓冲区”是一种缓存对索引写入的技术。 INSERT 和 DELETE 需要最终更新所有非唯一索引。此外，如果索引列发生更改，UPDATE 也需要执行同样的操作。此类更改被收集在“更改缓冲区”中，该缓冲区位于 buffer_pool 中。默认情况下，buffer_pool 的 25% 专用于此。

经过一定次数的修改后，更改缓冲区已满。此时，需要读取-修改-写入循环来更新包含索引的 BTree。这可能表现为吞吐量的下降。

同时，对于需要尚未更新的索引的查询怎么办？不是问题。根据需要检查 CB。 (额外的 CPU 周期以避免 I/O——通常是一个胜利。)

UUID对性能来说很糟糕——有时会出现“从悬崖上掉下来”的综合症。原因是它们的随机性，因此一旦表(或 uuid 索引)大于 buffer_pool 的容量，任何缓存都是无用的。 UUID 列通常被声明为UNIQUE(或PRIMARY)，因此需要在INSERT 上立即检查。也就是说，它不能在Change Buffer中被延迟。

如果你用UUID建表，很长一段时间，都可以缓存在buffer_pool中，吞吐量也不错。但最终表/索引变得太大，必要的 I/O 逐渐增加。当表大到可缓存的 20 倍时，只能在缓存中找到 1/20 的操作。

MSSql 怎么样？不同的供应商使用不同的技术来解决主要的性能 killer :磁盘。我不知道Oracle等是做什么的；但它可能有所不同，并且可能会由于 UUID 或缓存已满而遇到砖墙的其他变体。

(对于您所看到的内容可能还有其他解释。)