我很驚訝我在網站上和 MySQL 文件中都看不到這個問題的答案（第 5.2 節似乎已經記錄了其他方面的內容！
如果我啟用二進位日誌，我會看到一個小的效能影響（主觀上），這是預期的，需要一點額外的IO - 但是當我啟用通用查詢日誌時，我會看到一個巨大的效能影響（運行查詢的時間加倍，或者更糟），遠遠超出了我在二進位日誌中看到的內容。當然，我現在正在記錄每個 SELECT 以及每個 UPDATE/INSERT，但是其他守護程式會記錄它們的每個請求（Apache、Exim）而不會停止。
我是否只是看到了 IO 方面接近效能「臨界點」的影響，或者記錄查詢是否存在根本上的困難導致這種情況發生？我希望能夠記錄所有查詢以使開發更容易，但我無法證明我們需要透過常規查詢登入來恢復效能的硬體類型。
當然，我確實記錄了緩慢的查詢，如果禁用此功能，一般使用方面的改進可以忽略不計。
（所有這些都是在 Ubuntu 10.04 LTS、MySQLd 5.1.49 上進行的，但研究表明這是一個相當普遍的問題）
答案1
一般查詢日誌是很多比二進位日誌更多的 IO。除了大多數 SQL 伺服器的 90% 讀取和 10% 寫入這一事實之外，二進位日誌以二進位格式存儲，而不是使用較少磁碟空間的純文字格式。 （空間減少了多少？我不確定。抱歉。）
Apache 和 Exim 可以記錄每個請求而不會對效能產生重大影響，有兩個方面的原因。首先，他們記錄了請求發生的事實，但他們放入日誌中的內容通常比實際請求小得多。 HTTP 請求通常是日誌中的行的兩倍大，甚至一封簡短的純文字電子郵件也比其附帶的日誌行大 10 或 20 倍。帶有 10MB 附件的電子郵件在日誌中仍然只寫入幾行。
第二部分是，在普通的 Web 應用程式中，通常有數十個 SQL 查詢與單一 HTTP 頁面關聯。電子郵件的數量往往比 HTTP 請求的數量還要少。您的 MySQL 伺服器可能嘗試記錄比 Apache 或 Exim 更多的日誌。
在一天結束時查看 MySQL 二進位和常規日誌以及 Apache 和 Exim 日誌的大小（未壓縮）。我敢打賭，您會發現 MySQL 常規日誌是最大的日誌，其因子至少是 5 倍。
答案2
添加到提供的回答，如果您登入 MySQL 資料儲存所在的相同設備，您還會發現效能受到影響 - 如果是同一磁碟，您將一直讀取和寫入多個位置，從而減慢速度整個過程。
即使它是同一實體磁碟上的不同分割區也是如此。
如果日誌記錄到不同的設備，這應該會減輕一些的性能問題。