配置 InnoDB 的 redo 空間大小是寫密集型工作負載最重要的配置選項之一。不過，這需要權衡利弊。配置的 redo 空間越大，InnoDB 就能更好地最佳化寫 IO。不過，增加 redo 空間也意味著在系統斷電或因其他原因崩潰時需要更長的恢復時間。
對於特定的 innodb_log_file_size 值，要預測系統崩潰恢復所需的時間既不容易也不直接--這取決於硬體、MySQL 版本和工作負載。差異可能很大（視具體情況而定，相差 10 倍或更多）。不過，每 1GB innodb_log_file_size大約需要 5 分鐘是一個合適的粗略數字。如果這對你的環境真的很重要，建議在滿負荷情況下（資料庫完全預熱後）透過模擬系統崩潰來測試。
雖然恢復時間可以作為 InnoDB 日誌檔案大小限制的指導原則，但你還可以透過其他一些方法來檢視這個值--尤其是在安裝了 PMM的情況下。
檢視 PMM的 "MySQL InnoDB Metrics" 控制皮膚。如果你看到這樣的圖表
如果“Uncheckpointed Bytes”非常接近 "Max Checkpoint Age"，那麼幾乎可以肯定當前的 innodb_log_file_size 限制了系統的效能。增大innodb_log_file_size可以顯著提高效能。
如果看到的是這樣的內容：
“Uncheckpointed Bytes”數遠低於“Max Checkpoint Age”，那麼增加日誌檔案大小不會有明顯改善。
注意：許多 MySQL 設定是相互關聯的。對於較小的 innodb_buffer_pool_size 而言，特定的日誌檔案大小可能足夠大，但對於較大的 InnoDB Buffer Poo 值而言，可能需要更大的日誌檔案才能獲得最佳效能。
還有一點要記住：之前提到的恢復時間實際上取決於 Unchepointed Bytes，而不是日誌檔案的總大小。如果你沒有發現恢復時間隨著 innodb_log_file_size 的增大而增加，請檢視"InnoDB Checkpoint Age “圖--可能只是你的工作負載和配置無法充分利用大型日誌檔案。
另一種檢視日誌檔案大小的方法是檢視日誌空間使用情況：
此圖顯示了每小時寫入 InnoDB 日誌檔案的資料量以及 InnoDB 日誌檔案的總大小。在上圖中，我們有 2GB 的日誌空間，每小時寫入日誌檔案的資料約為 12GB。這意味著我們每十分鐘就要迴圈處理一次日誌。
InnoDB 必須在每個日誌檔案週期內至少重新整理一次緩衝池中的每個髒頁面。
如果重新整理頻率較低，InnoDB 的效能會更好，對 SSD 裝置的磨損也會更小。我希望重新整理時間不少於 15 分鐘,一小時更好。
手動估算，可以使用以下指令碼估算一下：
#!/bin/bash
USER="root"
PASS="root"
# Use command substitution to assign the output to a variable
a=$(mysql -u$USER -p$PASS -e"show engine innodb status\G" | grep "Log sequence number" | awk '{print $4}')
# The semicolon is not necessary when you move to a new line
mysql -u$USER -p$PASS -e"select sleep(60);"
b=$(mysql -u$USER -p$PASS -e"show engine innodb status\G" | grep "Log sequence number" | awk '{print $4}')
# Make sure to use the correct minus sign and not a dash character. Also, enclose the arithmetic operation inside $(( ))
mysql -u$USER -p$PASS -e"SELECT ((${b} - ${a}))*60/1024/1024 AS MB_Per_Hour;"