mysql慢查询原理_MySQL慢查询日志记录原理

一、慢查询日志

MySQL 慢查询日记用于记录 SQL 语句查询时间大于 MySQL 变量中定义的时间，以及可以选择定义记录没有使用索引的 SQL 查询语句。DBA 可以通过慢查询日志来找出有问题的 SQL 语句，对其进行优化。MySQL 慢查询日志默认关闭状态，所以需要通过开启 slow_query_log 参数来记录慢查询日志，并通过 long_query_time 参数定义记录慢查询日志的阈值才可开始使用慢查询日志的功能，long_query_time 参数的单位是毫秒；另外，还可以加 log-queries-not-using-indexes 参数，表示未使用索引的查询也被记录到慢查询日志中；log_slow_admin_statements 参数，表示是否记录管理语句。这几个参数都可以动态开启。

在 MySQL 5.7.2 之后，如果设置了慢日志是写到文件里，需要设置 log_timestamps(默认是 UTC 时间，比中国区晚 8 小时，需要设置为系统时间 log_timestamps=SYSTEM)来控制写入到慢日志文件里面的时区(该参数同时影响 general 日志和 error 日志)。如果设置慢日志是写入到数据库中，该参数将不产生作用。

慢查询日志中给出了账号、主机、运行时间、锁定时间、返回行等信息，然后根据这些信息来分析此 SQL 语句哪里出了问题。当开始使用慢查询功能后可能随着慢查询日志的越来越大，分析起来就不是那么容易了，这个时候就可以使用 MySQL 内置的 mysqldumpslow 工具来进行分析。

慢查询日志记录方式默认是在文件中，从 MySQL 5.1 开始支持记录到表中，这使得用户的查询更加方便和直观，如果想使用表需要管理员定义 log_output 参数。另外，同一般查询日志一样，慢查询日志可以直接删除。删除后在不重启服务器的情况下，需要执行 flush logs 语句重建日志文件。

二、慢查询记录机制

如果我们将语句的执行时间定义为：实际消耗时间 = 实际执行时间 + 锁等待消耗时间

那么 long_query_time 实际上界定的是实际执行时间，所以有些情况下虽然语句实际消耗的时间很长，但是是因为锁等待时间较长而引起的，那么实际上这种语句也不会记录到慢查询。概括来说就是语句实际执行时间(消耗时间 – 锁等待时间)大于 long_query_time 参数定义的时间时就会记录到慢查询日志。比如 l