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

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

如果启用binlog，我会发现（主观地）性能受到较小的影响，这会带来一些额外的IO，但是，当我启用常规查询日志时，就会看到巨大的性能影响（运行查询的时间增加了一倍，甚至更糟），远远超过了我在二进制日志中看到的内容。当然，我现在正在记录每个SELECT以及每个UPDATE / INSERT，但是其他守护程序会记录其每个请求（Apache，Exim），而不会停顿。

在IO方面，我只是刚刚看到接近性能“临界点”的影响，还是在日志记录查询中从根本上造成某种困难呢？我希望能够记录所有查询以简化开发，但是我无法证明那种感觉是我们需要通过常规查询登录来恢复性能的硬件。

我确实会记录慢速查询，并且如果禁用此功能，则一般用法的改进可以忽略不计。

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

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

为什么Apache和Exim可以记录每个请求而不会显着影响性能有两个方面。首先是他们记录一个请求已发生的事实，但是他们在日志中输入的内容通常比实际请求小得多。HTTP请求的大小通常是日志中行的两倍，甚至是简短的纯文本电子邮件也要比其随附的日志行大10或20倍。带有10MB附件的电子邮件在日志中仍然只写了几行。

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

最后查看一下MySQL二进制日志和常规日志以及Apache和Exim日志的大小（未压缩）。我敢打赌，您会发现MySQL常规日志是最大的日志，至少是其五分之一。

要添加到提供的答案中，如果您登录到与MySQL数据存储所在的设备相同的设备，则还会看到性能下降-如果它是同一磁盘，则将要在多个位置进行读写一直在拖延整个过程。

即使它是同一物理磁盘上的不同分区，也是如此。

如果将日志记录发送到其他设备，则可以缓解某些性能问题。