我很惊讶，我在网站上的任何地方都找不到这个问题的答案，在 MySQL 文档中也没有找到（第 5.2 节似乎已经记录好了！)
如果我启用 binlog，我会看到性能略有下降（主观上），这是预期的，因为有一点额外的 IO——但是当我启用一般查询日志时，我会看到巨大的性能下降（运行查询的时间增加一倍，甚至更糟），远远超过我在 binlog 中看到的情况。当然，我现在记录了每个 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 数据存储所在的同一设备，您还会看到性能下降 - 如果是同一个磁盘，您将一直读取和写入多个位置，从而减慢整个过程的速度。
即使它是同一物理磁盘上的不同分区，情况也是如此。
如果日志记录要转到不同的设备，这应该可以减轻一些性能问题。