MySQL慢查询日志默认关着，打开后别先把时间阈值设成10秒

MySQL装好之后，慢查询日志是关着的，long_query_time这个阈值默认10秒。两个默认值叠在一起，意味着大部分站点从来没留下过一份慢查询记录，等页面开始变卡，手上一点线索都没有，只能靠猜是哪张表的问题。

开启不需要重启，把slow_query_log和long_query_time都开到1，当前实例立刻开始记。要永久生效就得写进my.cnf的mysqld段，重启后仍然有效。默认的日志文件名是主机名接上-slow.log，落在数据目录里，没有给绝对路径的话会跟着datadir走，磁盘吃紧的时候记得把它挪到单独一块盘上，再配好日志轮转。

10秒这个阈值放在今天的业务上基本没用。一个接口超过一秒用户就能感觉到，能跑到10秒的早就是事故级别了。压到1秒甚至0.5秒，让它先记全，再慢慢把阈值收窄，比一上来就卡得很严要好用。这个值支持小数，写0.5就是500毫秒，改的是全局值时只影响新建立的连接，已经连上的会话要单独设置或者重连。

把几千条记录先归并成几十条

日志开了之后不要一条条读，mysqldumpslow会按语句模板归并，把具体变量换成占位符，同一类语句只出一条，附上执行次数、总耗时、平均耗时和扫描行数。压测一轮下来几千条记录，归并完通常只剩几十条，按总耗时排序，排在最前面的几条就是要动的。

Rows_examined和Rows_sent这两列在汇总里要放在一起看。前者是扫了多少行，后者是返回了多少行，两个数差得远，说明索引用得不对或者条件写得让它用不上索引。扫描几万行只返回十行，就是全表扫描的典型样子。这类语句拿EXPLAIN确认一下，重点看type那一列是不是ALL，以及key是不是空的。索引是内因，还有一类记录是被开关放大的，log_queries_not_using_indexes打开之后不走索引的语句即使很快也会被记下来。它的副作用同样明显，小表全扫也算进去，日志体量会迅速膨胀，一天下来几百兆很常见。配套的有log_throttle_queries_not_using_indexes，按分钟限速，默认0表示不限。真要开就设成几十，再配min_examined_row_limit把只扫几十行的小语句挡在外面，两个参数一起用才不至于把日志写爆。

慢日志是在语句执行完、锁也释放之后才写进去的，所以日志里的顺序不等于执行顺序，同一秒里几条慢语句谁先谁后看不出来。另外获取初始锁的时间不计入执行时间，一条语句在锁上等了5秒、自己只跑了0.2秒，日志里不会把它记成慢查询，可用户实打实等了5秒多。这一类要从performance_schema的等待事件里找，慢日志本身看不到，两个来源对着看才能拼出完整的时间线。