在MySQL更新查询中观察到突然下降
我已经描述了MySQL更新查询的性能。在稳定状态之后，吞吐量图中观察到突然下降。我已经多次重做了这些测试。我发现，对于同一场景，突然下降的地点并不相同。它随时间变化。我想知道这是因为在缓冲池中缓存而发生的吗？我使用MsSQL进行了相同的测试，我找不到这个问题。请帮助我解决这个问题。在MySQL更新查询中观察到突然下降
性能（对于大表）是关于磁盘命中的。和技巧来缓解这种情况。
需要更多的细节 - 如SHOW CREATE TABLE，SHOW TABLE STATUS和UPDATE。性能下降有多严重？ buffer_pool有多大？它的内存是多少？但这里有一些一般的答案。
“更改缓冲区”是一种缓存写入索引的技术。 INSERTs和DELETEs需要最终更新所有非唯一索引。另外，如果索引列更改，UPDATEs也需要这样做。这些更改会收集在buffer_pool中的“更改缓冲区”中。默认情况下，buffer_pool的25％专用于此类。
在一些数量的修改，改变缓冲区满。此时，需要读 - 修改 - 写周期来更新包含索引的BTrees。这个可能是可见的吞吐量下降。
同时，那需要的是尚未更新索引的查询？不是问题。 CB根据需要进行检查。 （额外的CPU周期，以避免I/O - 通常是一个胜利。）
UUIDs是可怕的表现 - 有时会有“跌倒悬崖”syndrone。原因在于它们是多么随机的，因此一旦表（或uuid索引）大于完全适合buffer_pool的程度，缓存是多么的无用。 UUID列通常被声明为UNIQUE（或PRIMARY），因此需要立即在INSERT上进行检查。也就是说，在Change Buffer中不能延迟。
如果您正在构建与UUID的表，很长一段时间，它都可以在BUFFER_POOL缓存和吞吐量是好的。但是最终表/索引变得太大，必要的I/O进入。当表的大小是缓存的20倍时，只有1/20的动作可以在缓存中找到。
什么MSSQL？不同的供应商使用不同的技术来解决主要的性能杀手：磁盘。我不知道甲骨文等是做什么的;但可能会有所不同，并且由于UUID或缓存已满，可能会遇到砖墙的其他变体。 （您可能会看到其他解释）