執行 Mysql 刪除查詢時，Mysql 是否創建任何臨時表？

伺服器詳情 我們有一個具有 3 個節點的 Galera 集群 Mariadb。在主節點上，數據庫大小為 200GB，磁碟空間大小為 400GB。在其他 2 個輔助節點上，數據庫大小為 200GB，磁碟空間大小為 240GB。

問題摘要：- 我們在主節點上針對一個大小為 100GB 的表執行了刪除查詢。在主節點上刪除查詢成功完成。但是在兩個輔助節點上，我們都面臨磁碟空間問題，並且一段時間後兩個輔助節點都關閉了。

請求：- 有人可以建議這裡發生了什麼以及 mysql 刪除查詢如何在內部工作。任何建議將不勝感激。

• 240GB 中的 200GB——太緊了。您可能無法執行ALTER. 其他查詢可能會耗盡磁碟空間。由於兩個節點如此緊密，因此很可能當它發生時，Galera 將失去仲裁併停止接受寫入。
• DELETE必須保存舊行以防發生ROLLBACK或崩潰。這就是導致崩潰的原因。
• 可能您現在唯一能做的就是炸掉兩個小節點並假裝您正在執行初始載入——讓一個活動節點重建另外兩個。
• 將來，保留一半的磁碟空閒。
• 將來，DELETE成塊的行。更多：http: //mysql.rjweb.org/doc.php/deletebig
• 查看您的架構（或將其提供給我們以供批評）。例如：ABIGINT佔用 8 個字節，但很少需要這麼大的數字；INT佔用一半的空間。同樣，請記住，更改BIGINT為INT 將涉及ALTER，這可能需要復製表 - 導致目前配置中的磁碟已滿。
• 同時，由於DELETE不能COMMIT在其他兩個 Galera 節點上，這應該在原始節點上觸發了故障。
• 始終檢查COMMITGalera 設置中的錯誤。
• OPTIMIZE TABLE對於小磁碟上的大文件不太可能是安全的。也就是說，我現在不認為它有用。以後也不行。

您的問題可能是由於您刪除的行數。

DELETE在 InnoDB 中，Galera 集群中的每個節點都必須為您在命令執行時刪除的每一行維護一個撤消日誌條目。

當DELETE命令完成時，節點 1 必須從節點 2 和節點 3 接收到事務已準備好在這些節點上送出的確認。因此，所有已刪除的行都將位於系統表空間文件（您的 ibdata1 文件）中並且會增長。

請注意 InnoDB 架構（Percona 首席技術官 Vadim Tkachenko 的圖片表示）

在這張圖片中，請注意作為撤消日誌的回滾段。您要刪除的所有行都堆積在其中，直到DELETE事務完成。當它送出時，已用空間不會被回收。這就是像這樣進行巨額交易的可悲現實。Node1 必須這樣做，Node2 和 Node3 也必須這樣做。

我曾在 8 年前發布過相關資訊：即使設置了 innodb_file_per_table，Innodb ibdata1 文件如何增長 5 倍？

這解釋了已用磁碟空間的去向。

您應該做的是一次刪除 1000 行的行。

這為 Node2 和 Node3 提供了消化刪除的喘息空間。反過來，ibdata1 在所有 3 個節點上都將保持其原始大小。

引用自：https://dba.stackexchange.com/questions/299983