MySQL 9.0 版本注意事項
InnoDB 是一個多版本儲存引擎。它會保留已變更列的舊版本相關資訊，以支援諸如並行性和回復等交易功能。此資訊儲存在復原表空間中，資料結構稱為復原區段。請參閱第 17.6.3.4 節「復原表空間」。InnoDB 使用復原區段中的資訊來執行交易回復中所需的復原操作。它也會使用資訊為一致性讀取建立列的較早版本。請參閱第 17.7.2.3 節「一致性非鎖定讀取」。
在內部，InnoDB 會將三個欄位新增至資料庫中儲存的每個列
一個 6 位元的
DB_TRX_ID欄位，指出最後插入或更新列的交易的交易識別碼。此外，刪除在內部被視為更新，其中會設定列中的特殊位元以將其標記為已刪除。一個 7 位元的
DB_ROLL_PTR欄位，稱為復原指標。復原指標指向寫入復原區段的復原日誌記錄。如果更新了列，復原日誌記錄會包含在更新之前重建列內容所需的資訊。一個 6 位元的
DB_ROW_ID欄位，其中包含隨著插入新列而單調遞增的列 ID。如果InnoDB自動產生叢集索引，則索引會包含列 ID 值。否則，DB_ROW_ID欄不會出現在任何索引中。
回滾區段中的復原日誌分為插入復原日誌和更新復原日誌。插入復原日誌僅在交易回滾時需要，且在交易提交後即可捨棄。更新復原日誌也用於一致性讀取，但只有在沒有任何交易存在時才能捨棄，而這些交易中 InnoDB 已指派快照，在一致性讀取中可能需要更新復原日誌中的資訊來建立資料庫列的早期版本。關於復原日誌的更多資訊，請參閱第 17.6.6 節「復原日誌」。
建議您定期提交交易，包括只發出一致性讀取的交易。否則，InnoDB 無法捨棄更新復原日誌中的資料，並且回滾區段可能會變得過大，填滿其所在的復原表空間。關於管理復原表空間的資訊，請參閱第 17.6.3.4 節「復原表空間」。
回滾區段中復原日誌記錄的實體大小通常小於相應的插入或更新列。您可以使用此資訊來計算回滾區段所需的空間。
在 InnoDB 多版本機制中，當您使用 SQL 語句刪除列時，不會立即從資料庫中實體移除該列。InnoDB 只會在捨棄為刪除所寫入的更新復原日誌記錄時，才會實體移除相應的列及其索引記錄。此移除操作稱為清除，速度相當快，通常與執行刪除操作的 SQL 語句所花費的時間相同。
如果您在表格中以大約相同的速率小批量地插入和刪除列，清除執行緒可能會開始落後，並且表格可能會因為所有「死」列而變得越來越大，使所有操作都受限於磁碟並變得非常緩慢。在這種情況下，請節制新的列操作，並通過調整 innodb_max_purge_lag 系統變數，為清除執行緒分配更多資源。如需更多資訊，請參閱第 17.8.9 節「清除組態」。
InnoDB 多版本並行控制 (MVCC) 對待次要索引的方式與叢集索引不同。叢集索引中的記錄會原地更新，其隱藏的系統欄會指向復原日誌條目，可以從中重建記錄的早期版本。與叢集索引記錄不同，次要索引記錄不包含隱藏的系統欄，也不會原地更新。
當次要索引欄更新時，舊的次要索引記錄會被標記為刪除，插入新的記錄，並且最終會清除被標記為刪除的記錄。當次要索引記錄被標記為刪除或次要索引頁面被較新的交易更新時，InnoDB 會在叢集索引中查找資料庫記錄。在叢集索引中，會檢查記錄的 DB_TRX_ID，如果記錄是在讀取交易啟動後修改的，則會從復原日誌中檢索正確版本的記錄。
如果次要索引記錄被標記為刪除或次要索引頁面被較新的交易更新，則不會使用涵蓋索引技術。 InnoDB 不會從索引結構傳回值，而是會在叢集索引中查找記錄。
但是，如果啟用了索引條件下推 (ICP) 最佳化，並且可以使用索引中的欄位來評估 WHERE 條件的一部分，則 MySQL 伺服器仍然會將 WHERE 條件的這一部分下推到儲存引擎，在該處使用索引進行評估。如果找不到相符的記錄，則會避免叢集索引查找。如果找到相符的記錄，即使是在被標記為刪除的記錄中，InnoDB 也會在叢集索引中查找記錄。