我已经分析了MySQL更新查询的性能。在稳定状态之后，吞吐量图中观察到突然下降。我已多次重做测试。我发现，突然下降的位置对于同一场景来说并不是同一点。它不时变化。我想知道这是因为缓冲池中的缓存而发生的？我使用MsSQL做了相同的测试我找不到这个问题。请帮我解决这个困惑。
答案 0 :(得分：0)
性能（对于大表）是关于磁盘命中的。并采取措施减轻这种情况。
需要更多详细信息，例如SHOW CREATE TABLE，SHOW TABLE STATUS和UPDATE。性能下降有多严重？ buffer_pool有多大？它的RAM分数是多少？但这里有一些一般的答案。
“更改缓冲区”是一种用于缓存对索引的写入的技术。 INSERTs和DELETEs需要最终更新所有非唯一索引。此外，如果更改了索引列，UPDATEs也需要这样做。这些更改收集在buffer_pool中的“change buffer”中。默认情况下，25％的buffer_pool专用于此类。
经过一些修改后，更改缓冲区已满。此时，需要读取 - 修改 - 写入周期来更新包含索引的BTree。 可能可视为吞吐量减慢。
同时，那些需要尚未更新的索引的查询呢？不是问题。根据需要检查CB。 （额外的CPU周期以避免I / O - 通常是赢。）
UUIDs 表现糟糕 - 有时候会有“摔下来”的综合症。原因是它们是多么随机，因此任何缓存都是无用的 - 一旦表（或uuid索引）大于完全适合buffer_pool。 UUID列通常声明为UNIQUE（或PRIMARY），因此需要立即在INSERT上进行检查。也就是说，它不能在更改缓冲区中延迟。
如果要使用UUID构建表，很长一段时间，它都可以缓存在buffer_pool中，并且吞吐量很好。但是最终表/索引变得太大而且必要的I / O很小。当表是缓存的20倍时，只能在缓存中找到1/20的操作。
MSSql 怎么样？不同的供应商使用不同的技术来解决主要的性能杀手：磁盘。我不知道甲骨文等是做什么的;但它可能是不同的，并且由于UUID或缓存已满而可能会遇到砖墙的其他变体。
（对于你所看到的内容，可能还有其他解释。）