刪除范圍內的十億條記錄與精確 ID 查找 MYSQL

Question

我有一個大約 700GB 的數據庫表，有1 Billion行，數據大約是 500GB，索引是 200GB，我正在嘗試刪除 2021 年之前的所有數據，到 2021 年大約有298,970,576行，還有708,337,583行剩余。

要刪除它，我正在我的 python shell 中運行不間斷查詢

DELETE FROM table_name WHERE id < 1762163840 LIMIT 1000000;

id -> 1762163840 代表 2021 年的數據。刪除 1 百萬行需要將近 1200-1800 秒。

有什么辦法可以加快這個速度，因為目前的方式已經運行了 15 天以上，而且到目前為止沒有太多數據刪除，而且還會持續更多天。

我想，如果我只用我要刪除的所有記錄的 id 創建一個表，然后執行一個確切的 map 之類的

DELETE FROM table_name WHERE id IN (SELECT id FROM _tmp_table_name);

會很快嗎？ 它會比首先創建一個包含所有記錄的新表然后刪除它更快嗎？

數據庫在 RDS 上設置，實例 class 是db.r3.large 2 vCPU 和 15.25 GB RAM，僅運行 4-5 個連接。

Answer 1

我建議重新創建您想要保留的數據 - 如果您有足夠的空間：

create table keep_data as
    select *
    from table_name
    where id >= 1762163840;

然后您可以截斷表並重新插入新數據：

truncate table table_name;

insert into table_name
    select *
    from keep_data;

這將重新創建索引。

缺點是重新插入數據仍然需要一段時間（重命名keep_data會更快）。 但它應該比刪除行快得多。

和。 . . 這將使您有機會對表進行分區，以便可以更快地處理未來的刪除。 如果你有這么大的表，你應該研究表分區。

Answer 2

它指出LIMIT 1000000不必要地大，並導致比可能需要的更多鎖定。

從長遠來看， PARTITIONing將是有益的，它提到了這一點。

如果您使用 Gordon 的技術（根據需要重建表格），您將在很長一段時間內無法訪問該表格； 我提供了一個基本為零停機時間的替代方案。

id IN (SELECT...)可能非常慢——既是因為 in-SELECT 的效率低下，也是因為 DELETE 將掛起大量行以實現事務完整性。