慢查询日志明明开了却一条记录都查不到？阈值设成默认一秒

slow_query_log显示ON，慢日志文件翻到最后一行，还是装好那天写的。站跑了两个月，一条新的都没进来，文件修改时间停在六月十一号。翻了两遍，确认不是自己看错了文件。

long_query_time的默认值是十秒，只有跑过十秒的语句才够格进日志。这个门槛高得离谱，接口慢到两秒用户已经在刷新，数据库这边一条不记。你要是照着网上那些帖子改，SET GLOBAL long_query_time=1，回车，日志还是空的。原因在这个变量同时是全局变量和会话变量，会话值在连接建立的那一瞬间从全局拷过来，之后各走各的。SET GLOBAL只改全局，老连接端着十秒的旧值不放。要么新开一个连接，要么在自己会话里再SET一次SESSION，查询才会被记下来。php-fpm的连接池恰好把老连接一直留着，所以很多人改完等于没改。

SHOW VARIABLES LIKE 'slow_query%'看开关和文件名，SHOW VARIABLES LIKE 'long_query_time'看阈值，两条一起执行。别只看配置文件里写的那行，mysqld启动时带的命令行参数优先级更高，两边不一致的时候以运行时为准。两个输出放一起看更直观。

开关开了、阈值也降了，日志仍然空，去看log_output。默认是FILE，改成TABLE以后慢查询写进mysql.slow_log这张表，文件当然不动。这张表可以直接select，排查时比翻文件方便，代价是每次写入都要过一遍存储层。查完记得改回FILE，不然下一个人还在找那个文件。

权限这类问题更隐蔽，slow_query_log_file指向的目录，mysqld进程得能写。Debian系的默认路径在/var/lib/mysql下面，属主就是mysql，不会有问题。有人把日志挪到/var/log/mysql，目录属主是root、权限750，mysqld进不去，启动日志里只留一行warning，很容易被跳过。还有一类是日志被logrotate切走，mysqld手里还攥着旧的文件描述符，新文件从创建那天起就是零字节。lsof查一下，句柄挂在带日期的归档文件上。mysqladmin flush-logs或者reload一次，它才重新打开新文件。

为了让日志里有东西，有人顺手打开log_queries_not_using_indexes。小站没走索引的查询一大把，日志一小时涨几个G，磁盘先满了。于是又把它关掉，关的时候连slow_query_log一起关了。这种连环误操作很常见，关之前看清楚关的是哪一个。一小时的日志抵得上平时一个月的量。

验证的办法是在库里跑一句SELECT SLEEP(3)。阈值设成一秒的话，日志里马上多一条，几秒钟之内就能看见。没多，就是前面某个环节没通，别急着去改代码。

日志有了还得能读，mysqldumpslow按次数和总耗时排序，pt-query-digest分得更细，通常前十条就占掉大半时间。先动那几条，比从头翻到尾有效。顺手记个基线：每天多少条、最慢几秒、哪张表出现最多。一个月之后回头看，哪类问题反复冒头就很清楚了。