Mysql
InnoDB 中的 B-tree 是否使用標記刪除？
我了解到 InnoDB 中的所有二級 B 樹都儲存表單對（搜尋鍵，TID），其中 TID 是記錄的主鍵。我有以下問題：
（1）在InnoDB中，二級B-Tree是否通過mark-deletion實現刪除？即葉子中的條目被標記為刪除而不是物理刪除。
（2）如果是這樣，當插入一個新的條目，其搜尋鍵與一些現有的標記刪除條目相同時，InnoDB如何確定標記刪除條目是否已送出？例如，假設 B 樹是唯一索引。假設第一個事務標記刪除搜尋鍵
hello，第二個事務嘗試插入搜尋鍵hello。如果第一個事務尚未送出，則插入應該失敗；否則，插入應該是成功的。我想知道 InnoDB 如何決定是否允許插入hello。
對你的問題大多是“不”。
讓我回顧一下 InnoDB 如何處理二級索引的幾個方面。
- 它們與數據一樣儲存在“B+Trees”（參見 Wikipedia）中。
- 數據 B+Tree 由
PRIMARY KEY.- 每個二級索引（無論是否 UNIQUE）都儲存在單獨的 B+Tree 中，按索引中定義的鍵排序。
- BTree 為 16KB（預設）。因此，大約 100 個數據或索引“行”可以保存在一個塊中。
- 由於獲取塊（從磁碟，或將其定位在 buffer_pool（參見“innodb_buffer_pool_size”））是大部分工作，因此沒有“標記”的概念以供以後刪除。
UNIQUE在事務處理的早期檢查密鑰；重複將導致“鎖定等待超時”或“死鎖”或“重複鍵錯誤”。- 非唯一索引在“更改緩衝區”中暫存/記憶體，該緩衝區分配在 buffer_pool 的一部分（預設為 25%）中。這有一個掛起的索引更改列表（插入/更新/刪除）。它們被收集、排序並最終用於更新索引塊。
- 更改緩衝區的目標是減少索引更改的 I/O。它具有更有效地處理刪除的效果。
- 因此，在某種程度上，更改緩衝區就是它“標記刪除”的方式。
- 在數據 BTree 中，保存了一個“歷史列表”，其中包含對數據的未決更改。這是 MVCC 如何工作以及多個事務如何在各種“事務隔離模式”下成功工作的核心組件，即使某些事務最終被 ROLLBACK’d。
可能還有更多。
引用的內容是 MySQL 文獻中進一步研究的關鍵主題。