為什麼 MySQL 需要兩個或更多的 InnoDB 重做日誌文件？
單個重做日誌文件也可以以循環方式寫入。
事實上，MariaDB 已將其 InnoDB 重做日誌更改為單個文件，其開發人員聲稱“日誌文件被不必要地拆分為多個文件，在邏輯上被視為一個大循環文件”和“原來是單個固定大小循環日誌文件在典型場景中表現最佳”（參見）。
那麼為什麼 MySQL 會選擇使用多個重做日誌文件呢？與使用單個日誌文件相比有什麼優勢嗎？
（我沒有太多支持這個答案。但我對歷史了解很多。）
Innobase的最初實現者（Heikki Tuuri 在 2000 年左右）認為兩個文件之間的 ping-ponding 是正確的方法，所以這就是他實現的。MySQL 建立了處理各種“引擎”的機制並吸收了 Innobase，將其重命名為 InnoDB。
有一些證據表明，超過 2 個文件實際上會適得其反。
哲學在那之後，“如果它沒有壞，就不要修理它”。MySQL 似乎總是抱著只增強真正需要的東西的態度。
有些事情得到實施（或修復），因為單個客戶要麼送出程式碼，要麼付費完成。
我想沒有人認為
innodb_log_files_in_group壞到足以修復。查詢記憶體正在消失（在 MySQL 中消失）。它是在 2000 年之前實施的，以在某些基準測試中擊敗競爭對手。但它的實現方式很笨拙。一旦多主和集群拓撲變得流行，QC 就不得不離開。QC 不能輕易複製。Aurora 至少重新實現了它以更好地擴展。
MyISAM幾乎被 MySQL（但不是 MariaDB）棄用。它也不能很好地與集群配合使用。
MariaDB.com 擁有一些 1990 年代的 MySQL 開發人員。
我已經與 InnoDB 開發人員討論過這個問題。
事實證明，InnoDB 從來沒有充分的理由預設使用兩個重做日誌文件。原因是它模仿了 Oracle 的預設設置。
Oracle 使用它的重做日誌文件，就像 MySQL 使用 InnoDB 日誌文件（用於數據庫恢復）和二進制日誌文件（用於複製）一樣。在 MySQL 中，這些是獨立的特性，因為二進制日誌獨立於儲存引擎，而重做日誌僅用於 InnoDB。但是在 Oracle 中，沒有可插拔的儲存引擎，因此所有功能都可以協同工作。
在 Oracle 的實現中，值得擁有多個重做日誌文件來支持日誌歸檔。在歸檔“非活動”文件時需要一個“活動”重做日誌文件（有關詳細資訊，請參閱管理重做日誌）。
InnoDB 不做重做日誌的日誌歸檔，因為二進制日誌可以實現這個目的。因此，活動文件和非活動文件的 InnoDB 重做日誌沒有區別。
那麼為什麼預設有兩個 InnoDB 重做日誌文件呢？只是因為 InnoDB 的創始人 Heikki Tuuri 有使用 Oracle 的經驗，並且他有一個願景，那就是實現一個可以做類似事情但實現更好的數據庫引擎。因此，InnoDB 中的一些選項和預設設置是基於這樣的假設，即它的工作方式至少與 Oracle 有點相似。
事實上，InnoDB 使用兩個重做日誌文件從來沒有任何優勢。但是更改該預設值也沒有顯著優勢。即使 MariaDB 已決定更改預設設置，我懷疑它是否會產生足夠的差異來證明其性能是否合理。
我的意思是，如果使用一個重做日誌文件而不是兩個重做日誌文件的微小差異是您認為需要做的優化，那麼您可能應該考慮其他更重要的改進，例如優化您的查詢或移動到分片架構，因此您可以將數據庫寫入流量拆分到多個伺服器上。
但是為了簡化軟體的操作，或者消除對此類問題的困惑，更改預設值當然是一個合理的選擇。