日誌記錄會損害 MySQL 的性能——但是，為什麼？
我很驚訝我已經在網站上的任何地方都看不到這個問題的答案，在 MySQL 文件中也看不到答案（第 5.2 節似乎已經很好地涵蓋了日誌記錄！）
如果我啟用二進制日誌，我會看到一個小的性能損失（主觀上），這是可以預期的，需要一點額外的 IO ——但是當我啟用一個通用查詢日誌時，我會看到一個巨大的性能損失（執行查詢的時間加倍，或更糟），遠遠超過我在二進制日誌中看到的。當然，我現在正在記錄每個 SELECT 以及每個 UPDATE/INSERT，但是，其他守護程序會記錄它們的每個請求（Apache、Exim）而不會停止。
我只是看到在 IO 方面接近性能“臨界點”的影響，還是在記錄導致這種情況發生的查詢方面存在根本性的困難？我希望能夠記錄所有查詢以使開發更容易，但我無法證明我們需要通過一般查詢登錄來恢復性能的那種硬體。
當然，我會記錄慢速查詢，如果我禁用它，一般使用的改進可以忽略不計。
（所有這些都在 Ubuntu 10.04 LTS、MySQLd 5.1.49 上，但研究表明這是一個相當普遍的問題）
一般查詢日誌的IO 比二進制日誌多**很多。**除了大多數 SQL 伺服器是 90% 讀取到 10% 寫入這一事實之外，二進制日誌以二進制格式儲存，而不是使用較少磁碟空間的純文字。（少了多少空間？我不確定。抱歉。）
為什麼 Apache 和 Exim 可以記錄每個請求而不會對性能產生重大影響，這有兩個方面。首先是他們記錄了請求發生的事實，但他們放在日誌中的內容通常比實際請求小得多。HTTP 請求通常是日誌行的兩倍，即使是簡短的純文字電子郵件也比日誌行大 10 或 20 倍。帶有 10MB 附件的電子郵件在日誌中仍然只有幾行。
第二部分是在一個普通的 Web 應用程序中，通常有幾十個 SQL 查詢與單個 HTTP 頁面相關聯。電子郵件的數量往往比 HTTP 請求的數量還要少。您的 MySQL 伺服器可能試圖記錄比 Apache 或 Exim 更多的日誌。
在一天結束時查看 MySQL 二進制和正常日誌以及 Apache 和 Exim 日誌的大小（未壓縮）。我敢打賭，你會發現 MySQL 通用日誌是最大的日誌，至少是 5 倍。