日志记录会损害 MySQL 性能 - 但是，为什么呢？

Question

我很惊讶我在网站上的任何地方都看不到这个答案，也没有在 MySQL 文档中看到这个答案（第 5.2 节似乎已经很好地涵盖了日志记录！）

如果我启用 binlogs，我会看到一个小的性能损失（主观上），这在一些额外的 IO 下是可以预料的——但是当我启用一个通用查询日志时，我看到一个巨大的性能损失（运行查询的时间加倍，或更糟），远远超过我在二进制日志中看到的内容。当然，我现在正在记录每个 SELECT 以及每个 UPDATE/INSERT，但是，其他守护进程会记录他们的每个请求（Apache、Exim）而不会停止。

当涉及到 IO 时，我是否只是看到接近性能“临界点”的影响，或者日志查询是否存在一些根本性的困难导致这种情况发生？我希望能够记录所有查询以使开发更容易，但我无法证明我们需要通过一般查询登录来恢复性能的硬件类型。

当然，我会记录慢查询，如果禁用它，一般使用的改进可以忽略不计。

（所有这些都在 Ubuntu 10.04 LTS、MySQLd 5.1.49 上，但研究表明这是一个相当普遍的问题）

Answer 1

一般查询日志是很多不是二进制日志的IO。除了大多数 SQL 服务器是 90% 读取到 10% 写入这一事实之外，二进制日志以二进制格式存储，而不是使用较少磁盘空间的纯文本。（少多少空间？我不确定。抱歉。）

Apache 和 Exim 可以记录每个请求而不会对性能产生重大影响的原因有两个方面。第一个是他们记录了请求发生的事实，但他们放入日志的内容通常比实际请求小得多。HTTP 请求通常是日志中行的两倍大，即使是简短的纯文本电子邮件也比随附的日志行大 10 或 20 倍。带有 10MB 附件的电子邮件仍然只会在日志中写入几行。

第二部分是，在普通的 Web 应用程序中，通常有几十个 SQL 查询与单个 HTTP 页面相关联。电子邮件的数量往往比 HTTP 请求的数量还要少。您的 MySQL 服务器可能正在尝试记录比 Apache 或 Exim 多得多的日志。

在一天结束时查看 MySQL 二进制文件和常规日志以及 Apache 和 Exim 日志的大小（未压缩）。我敢打赌，您会发现 MySQL 常规日志是最大的日志，至少是 5 倍。