在MySQL更新查詢中觀察到突然下降

Question

我已經描述了MySQL更新查詢的性能。在穩定狀態之後，吞吐量圖中觀察到突然下降。我已經多次重做了這些測試。我發現，對於同一場景，突然下降的地點並不相同。它隨時間變化。我想知道這是因爲在緩衝池中緩存而發生的嗎？我使用MsSQL進行了相同的測試，我找不到這個問題。請幫助我解決這個問題。

Answer 1

性能（對於大表）是關於磁盤命中的。和技巧來緩解這種情況。

需要更多的細節 - 如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或緩存已滿，可能會遇到磚牆的其他變體。 （您可能會看到其他解釋）