我们发现什么是mysql慢查询日志参数的最佳设置，为什么？

解决方案

无论何时，我们/我们/在系统上进行查询的速度都令人无法接受。

这取决于我们运行的查询类型和系统类型。如果是某些后端报告系统执行复杂的数据挖掘等，而延迟并不重要，那么花费几秒钟的查询就可能无关紧要，但是对于面向用户的系统而言，这可能是完全不可接受的，因为预期该系统会迅速返回结果。

将其设置为任何我们喜欢的。唯一的问题是，在现有的MySQL中，只能以1秒为增量进行设置，这对于某些人来说太慢了。

使用最频繁的生产服务器执行太多查询，无法全部记录。慢日志是一种过滤日志的方式，以便我们可以看到花费很长时间的日志(大多数查询可能几乎立即执行)。这是一个钝器。

如果愿意，将其设置为1秒，这样做可能不会耗尽磁盘空间或者造成性能问题。

如果我们认为很可能导致进一步的光盘或者性能问题，则启用慢速日志记录不执行此操作确实有风险。

当然，我们可以在非生产服务器上启用慢速日志记录并进行模拟负载，但这绝不是完全一样的。

就分辨率而言，它不仅是一种过时的工具，而且在MySQL实例范围内，因此，如果我们具有性能要求不同的不同数据库，那么我们将很不走运。显然，有很多方法可以解决此问题，但是在设置慢日志设置时，请记住这一点很重要。

除了应用程序的性能要求之外，要考虑的另一个因素是我们要记录的内容。我们是否在使用日志来捕获可能威胁数据库实例稳定性的查询(例如，导致死锁或者笛卡尔联接的查询)或者影响特定用户性能并可能需要稍作调整的查询？这将影响我们设置阈值的位置。

我推荐这三行

log_slow_queries
set-variable = long_query_time=1
log-queries-not-using-indexes

第一和第二将记录所有查询。正如其他人指出的那样，如果我们正在为网站上的高交易率而射击，那么一秒钟的查询已经远远没有了，但是我发现它带来了一些真正的WTF；应该是快速的查询，但是对于它所针对的数据组合却不是这样。

最后一个将记录任何不使用索引的查询。除非我们进行数据仓库存储，否则任何常见查询都应具有最佳索引，因此请注意其输出。

尽管它肯定不适合生产，但最后一个选择

log = /var/log/mysql/mysql.log

将记录所有查询，这在我们尝试调整特定页面或者操作时很有用。

Peter Zaitsev发表了一篇有关使用慢查询日志的不错的文章。他指出的一件事很重要，那就是还要考虑使用某个查询的频率。每天运行一次报表对于保证快速运行并不重要。但是，即使花费半秒钟，经常运行的某些东西也可能会成为问题。如果没有microslow补丁，我们将无法检测到。