預設的 MySQL 設定 AUTOCOMMIT=1 會對繁忙的資料庫伺服器造成效能限制。在可行的情況下，將數個相關的資料變更操作包裝到單一交易中，方法是發出 SET AUTOCOMMIT=0 或 START TRANSACTION 語句，然後在進行所有變更後發出 COMMIT 語句。

如果交易對資料庫進行了修改，InnoDB 必須在每次交易提交時將日誌刷新到磁碟。當每次變更後都跟著一個提交時（如同預設的自動提交設定），儲存裝置的 I/O 輸送量會限制每秒的潛在操作次數。

或者，對於僅包含單一 SELECT 語句的交易，啟用 AUTOCOMMIT 有助於 InnoDB 辨識唯讀交易並進行最佳化。請參閱 第 10.5.3 節「最佳化 InnoDB 唯讀交易」以了解需求。

避免在插入、更新或刪除大量列後執行回滾。如果大型交易正在減慢伺服器效能，回滾可能會使問題更糟，可能需要比原始資料變更操作長數倍的時間才能執行。終止資料庫程序沒有幫助，因為回滾會在伺服器啟動時重新開始。

為了盡量減少此問題發生的機會

為了擺脫失控的回滾，一旦發生，增加緩衝池，使回滾變成受 CPU 限制並快速執行，或者關閉伺服器並使用 innodb_force_recovery=3 重新啟動，如第 17.18.2 節「InnoDB 復原」中所述。

如果您可以承受在發生意外退出時遺失一些最新的已提交交易，您可以將 innodb_flush_log_at_trx_commit 參數設定為 0。InnoDB 嘗試無論如何每秒刷新日誌一次，儘管無法保證刷新成功。

當修改或刪除列時，列和相關的撤銷日誌不會立即實際刪除，甚至在交易提交後也不會立即刪除。舊資料會被保留，直到較早開始或同時進行的交易完成，以便這些交易可以存取修改或刪除列的先前狀態。因此，長時間執行的交易可能會阻止 InnoDB 清除由其他交易變更的資料。

當在長時間執行的交易中修改或刪除列時，使用 READ COMMITTED 和 REPEATABLE READ 隔離層級的其他交易，如果讀取相同的列，則必須執行更多工作來重建舊的資料。

當長時間執行的交易修改資料表時，來自其他交易對該資料表的查詢不會使用覆蓋索引技術。通常可以從輔助索引擷取所有結果欄的查詢，會改為從資料表資料中查找適當的值。

如果發現輔助索引頁面的 PAGE_MAX_TRX_ID 太新，或者輔助索引中的記錄已標記為刪除，InnoDB 可能需要使用叢集索引查找記錄。