我們觀察到一些查詢的高延遲，進一步探勘我們發現每 5 分鐘查詢一次通過檢查慢查詢日誌需要很長時間。

我們觀察到

PURGE BINARY LOGS TO 'mysql-bin-changelog.041045';

每 5 分鐘執行一次，耗時超過 1000 毫秒。同時查詢如

SET timestamp=1492673425; commit;

也需要時間和

SELECT @@session.tx_isolation;

我們在 Amazon RDS 上使用 MySQL 5.7.11。為什麼PURGE BINARY LOGS會花費更長的時間並導致其他查詢也同時卡住？

這是我 2 個月前在 RDS 之外經歷過的 MySQL 5.7 中一個相當討厭的錯誤。有一種奇怪的互斥行為涉及清除二進制日誌的行為。

我的解決方法是手動刪除 bin-log.index 中列出的作業系統中的一些二進制日誌並執行PURGE BINARY LOGS BEFORE CURDATE() + INTERVAL 2 HOUR;（每凌晨 2 點清除一次）。它加快了速度，因為它在作業系統中檢查的文件更少。當涉及到仍然存在的實際 binlog 時，執行PURGE BINARY LOGS ...只是被拖了。這就是為什麼我做了手動煙霧和鏡子的東西。

您的實際情況

在您的特定實例中，您使用的是 RDS。由於您無法進入作業系統，因此您無法對 binlogs 執行任何其他操作，因為無法在 RDS 參數組中更改max_binlog_size 。如果您有大量或許多事務需要在寫入二進制日誌之前記憶體，您可以更改max_binlog_cache_size，但這可能會或可能不會有幫助，具體取決於您在應用程序中寫入的頻率。

推薦

MySQL 5.6 中不存在此問題。

您可能必須將數據庫遷移回 MySQL 5.6.27 RDS。

結語

根據我的經驗，我是 MySQL 5.7.12 中這個 bug 的受害者。您告訴我該錯誤已在 MySQL 5.7.14 中得到解決。我希望我已經像我想要的那樣升級了。由於您的情況出現在 MySQL 5.7.11 上，我知道除了我之外的其他人注意到了這個問題。盡快升級到 5.7.16。祝你有美好的一天 ！！！

引用自：https://dba.stackexchange.com/questions/171505