MySQL 中刪除的數(shù)據(jù)都去哪兒了？
本文轉(zhuǎn)載自微信公眾號「SH的全棧筆記」，作者SH的全棧筆記 。轉(zhuǎn)載本文請聯(lián)系SH的全棧筆記公眾號。
不知道大家有沒有想過下面這件事?
我們平時調(diào)用 DELETE 在 MySQL 中刪除的數(shù)據(jù)都去哪兒了?
這還用問嗎?當(dāng)然是被刪除了啊
那么這里又有個新的問題了，如果在 InnoDB 下，多事務(wù)并發(fā)的情況下，如果事務(wù)A刪除了 id=1 的數(shù)據(jù)，同時事務(wù)B又去讀取 id=1 的數(shù)據(jù)，如果這條數(shù)據(jù)真的被刪除了，那 MVCC 拿啥數(shù)據(jù)返回給用戶呢?
沒錯，這就需要了解一下 MySQL 的多版本并發(fā)的原理相關(guān)的東西，感興趣的可以去看我之前寫的這篇文章。
所以，實(shí)際情況中，調(diào)用了 DELETE 語句刪除的數(shù)據(jù)并不會真正的被物理刪除，這條數(shù)據(jù)其實(shí)還在那，只不過被打上了一個標(biāo)記，標(biāo)記已刪除。
這其實(shí)跟我們?nèi)粘５牟僮?mdash;—軟刪除，差不多是一個意思
在 MySQL 中， UPDATE 和 DELETE 操作本質(zhì)上是一樣的， 都屬于更新操作，刪除操作只不過是把某行數(shù)據(jù)中的一個特定的比特位標(biāo)記為已刪除，僅此而已。
那么問題又來了，那這些刪除的數(shù)據(jù)如果一直這么堆下去，那不早晚把硬盤撐爆?
如果都玩兒成這樣了，那 MySQL 還能像現(xiàn)在這樣被大規(guī)模的用于生產(chǎn)環(huán)境中嗎?那 MySQL 到底是怎么玩的?
這就需要提到 Purge 操作了。
Purge操作是啥?
Purge 操作才是真正將數(shù)據(jù)(已被標(biāo)記為已刪除)物理刪除的操作。
Purge 操作針對的數(shù)據(jù)對象，不僅僅是某一行，還有其對應(yīng)的索引數(shù)據(jù)和 Undo Log。
好的那么問題又來了。
問題是，Purge 操作什么時候會執(zhí)行呢?實(shí)際上，你可以將執(zhí)行 Purge 操作的線程(簡稱 Purge 線程)理解成一個后臺周期性執(zhí)行的線程。
Purge 線程可以有一個，也可以有多個，具體的線程數(shù)量可以由 MySQL 的配置項(xiàng) innodb_purge_threads 來進(jìn)行配置。當(dāng)然，我相信你肯定不記得在使用 MySQL 的時候配置過這個，因?yàn)?innodb_purge_threads 有個默認(rèn)值，值為 4。
InnoDB 會根據(jù) MySQL 中表的數(shù)量和 Purge 線程的數(shù)量進(jìn)行分配。
但正是因?yàn)橛羞@種特性，Purge 線程的數(shù)量才需要根據(jù)業(yè)務(wù)的實(shí)際情況來做調(diào)整。舉個例子，假設(shè) DML 操作都集中在某張表，比如表1上...
你先等等，我打斷一下......
什么叫 DML 操作?總喜歡搞些復(fù)雜的名詞...DML(Data Manipulation Language)數(shù)據(jù)操作語句，實(shí)際上就是CRUD增刪改查...
與之類似的概念還有DDL(Data Definition Language)數(shù)據(jù)定義語句，也就是CREATE、DROP和ALTER等等.
以及DCL(Data Control Language)數(shù)據(jù)控制語句，也就是GRANT、REVOKE等等...
繼續(xù)說回來，雖然 Purge 線程的數(shù)量是可配置的，但是也不是你想配多少就配多少的。不然你給它干個 10000 個線程，那不就直接原地 OOM 了嗎?
innodb_purge_threads 的最大值為 32，而且并不是我們配了 32 InnoDB 就真的會啟動 32 個 Purge 線程，為啥呢?舉個很簡單的例子，假設(shè)此時只有一張表，然后我們配置了 32 個 Purge 線程。
你看著上面這個圖問問自己，這「河里」嗎?這樣不僅浪費(fèi)了系統(tǒng)的資源，同時還使得不同的 Purge 線程之間發(fā)生了數(shù)據(jù)競爭。不僅如此，Purge 線程還可能跟用戶線程產(chǎn)生競爭。
但是當(dāng)系統(tǒng)中真的有 32 張表的時候，情況又不一樣了，一個 Purge 線程對應(yīng)一張表，線程與線程之間就不會存在數(shù)據(jù)競爭，并且沒有浪費(fèi)系統(tǒng)資源，還能夠提升執(zhí)行 Purge 操作的性能。
這就是為啥 InnoDB 會根據(jù)實(shí)際情況來調(diào)整 MySQL 中 Purge 線程的數(shù)量，所以我們在配置的時候也要按照實(shí)際情況來設(shè)置。
舉個例子，如果你的數(shù)據(jù)庫中，增刪改 的操作只集中在某幾張表上，則可以考慮將 innodb_purge_threads 設(shè)置的稍微低一點(diǎn)。相反，如果 增刪改 的操作幾乎每張表都有，那么 innodb_purge_threads 就可以設(shè)置的大一些。
了解完 Purge 線程本身之后，我們就可以來了解 Purge 線程所針對的對象了。Purge 線程主要清理的對象是 Undo Logs，其次是行記錄。
因?yàn)?Undo Log 可以分為：
- Insert Undo Log
- Update Undo Log
所以更準(zhǔn)確的說法是，Purge 線程清理的對象是 Update Undo Log 和 行記錄，因?yàn)?Insert Undo Log 會在事務(wù)提交之后就會被刪除。
我們都知道 InnoDB 的 MVCC 的數(shù)據(jù)來源是一個一個 Undo Log 形成的單鏈表，而 Purge 線程就是用于定期清理 Undo Log 的，并且在清理完 刪除數(shù)據(jù)所生成的 Undo Log 的時候，就會把對應(yīng)的行記錄給移除了。
那么問題又來了，Purge 線程每次會讀取多少條件 Undo Log 記錄呢?
很明顯，它不是看當(dāng)時的心情來決定取多少條的。它是通過配置項(xiàng) innodb_purge_batch_size 來控制的，默認(rèn)是 300。然后InnoDB會將這300條 Undo Log 分給innodb_purge_threads個 Purge 線程。在清理的過程中，Purge 線程還會釋放 Undo Log 表空間內(nèi)的文件。
