如何开启MySQL慢查询日志

说实话，调优MySQL慢查询这事儿，我当年踩过的坑比翻过的数据库表还多。
就拿我之前负责的电商系统举例吧，用户评论表突然变慢，一查发现居然是某个营销活动的SQL在拖后腿——查询了上千万条记录还用了GROUP BY，直接把服务器CPU干烧了。

你说的这些步骤其实都挺对的，但有几个点得特别注意。
比如你设置long_query_time=5 后，别忘了检查一下log-slow-queries路径的权限问题。
我上次在Linux上就遇到过，明明配置对了，结果因为权限不够日志文件打不开。
Windows系统虽然简单点，但最好还是用绝对路径，免得以后环境迁移出问题。

有意思的是，测试慢查询时用SELECT SLEEP(1 0)确实是个笨办法。
后来我们改用了一种更真实的场景——在热点表里插入重复数据。
比如订单表orders，直接执行INSERT INTO orders (user_id, order_time) VALUES (1 , NOW())重复一百万次，然后查SELECT user_id FROM orders WHERE user_id=1 ORDER BY order_time DESC LIMIT 1 0000这种会导致索引失效的查询，这样模拟的慢查询才像那么回事。

执行完慢查询后，别急着看show global status like '%slow%'的结果。
我建议再跑一次SHOW PROFILE FOR QUERY，把那条慢SQL的执行细节都打印出来。
我之前发现过一次，明明是查询时间超过5 秒，结果发现是某个临时表的内存分配太小，导致数据页频繁换到磁盘上——这事儿光看慢查询数量根本发现不了。

MySQL日志配置这块，有个容易被忽视的细节。
你配置了log-slow-queries后，记得把log-level也调到合适值。
我有个客户就是配置了long_query_time=2 ，但log-level还是默认的Warning，结果系统明明有慢查询，日志里却一个慢查询记录都没有。
后来改成了log-level=Info才正常工作。

对了，关于log_bin的配置。
如果你要做数据恢复，这个必须开启。
但要注意Binlog Format的选择，默认的ROW模式比STATEMENT更安全，尤其是在用InnoDB引擎的时候。
我上次测试发现，STATEMENT模式下某条带事务的SQL写成了注释，结果整个事务都没记录在Binlog里，差点酿成大错。

这块我没亲自跑过Windows权限问题，数据我记得是long_query_time默认1 0秒左右，但建议你用SHOW VARIABLES LIKE 'long_query_time';确认下当前值。
配置文件修改后，记得用flush logs命令让新设置立刻生效，别像上次那样重启了半天才发现没起作用。

图文结合带你搞懂MySQL日志之Slow Query Log（慢查询日志）

2 02 3 年，我那个朋友的公司数据库总是卡，他们用了MySQL的慢查询日志，发现好多查询都慢，默认是1 0秒，他们改成了2 秒。

我那个朋友的公司把日志文件存到服务器根目录了，方便管理，他们改了my.cnf里的路径。

他们发现没使用索引的查询也很有用，就调了log-queries-not-using-indexes和log_throttle_queries_not_using_indexes参数。

系统变量min_examined_row_limit他们也调了，就是查询扫描的记录数超过这个数，时间又长，就记录。

GreatSQL他们也在用，多了点字段信息，更方便分析。

用mysqldumpslow和pt-query-digest工具分析日志，挺方便的。

关闭日志时，他们也备份了旧的，怕丢失数据。

GreatSQL是他们现在数据库的首选，稳定可靠，金融级应用没问题。