慢日志那点事

慢查询日志作用：
用来定位MYSQL 的第一个步骤，慢日志+explain+索引能够解决80%以上的问题；
其他可能是参数出错；底层的问题；

**可辅助解决：**数据库很慢，CPU打满，很卡；问题定位

**慢查询日志：**将运行超过某个时间阈值的SQL记录到文件：
5.1开始可以以毫秒为单位记录运行的SQL语句；
5.5可以将慢查询保存到表；
5.6可以更细粒度的写入；
5.7可以写入时区信息；此为坑

慢日志相关参数：
slow_query_log：是否开启慢查询日志；
slow_query_log_file：慢查询日志文件名;
long_query_time ：指定慢查询阈值，默认是10秒(只开启慢日志时，slow_query_log)；记录大于，等于不记；单位是秒；
log_queries_not_using_indexes ： 将没有使用索引的SQL记录到慢查询日志；虽然可以记录慢查询，虽然小于阈值，但这些语句也是有问题，可能当数据量变大时，可能会出现问题的；好处是在前期就可以将此语句拖出来 ; （有些已经用到索引，但因为是嵌套表，所以也被记录；）
log-throttle_queries-not-using-indexes:throttle 用来限制每分钟只记录多少没有使用索引的SQL 的次数；没有使用到索引的话，也就是全表扫描的，数据量不大，如100个页，如果设置log-queries-not-using-indexes：查询时间不用超过阈值，这些查询会不断的产生，这样慢查询的日志会越来越大，
min_examined_row_limit：扫描记录少于该值 的SQL不记录到慢查询日志;因为一旦开启log-queries-not-using-indexes,的话，所有没有引用索引的SQL都会记录下来，但有些表是数据字典表，记录少，如果把这些扫描记录数少于该值的就不记录到慢查询日志了；这就是为了更有粒度的记录慢查询日志；
log-slow-admin-statement：记录管理操作，如ALTER\ANALYZE TABLE，都会记录到慢日志中；默认不记录；
log_output： （5.5版本来始支持到表）慢查询日志的格式（file|table|none)
long_slow_slave_statement：在从库上也开启慢查询日志;
log_timestamps=system写入时区信息；–5.7引入，可以根据系统或utc（世界统一时间）时间；
默认为UTC时间；只有在5.7版本才起效； 可以不用；

可以在线设置;
set global slow_query_log = 1;
set global long_query_time =3;

Q1:哪些情况执行时间很长，却不记录在慢日志中？
slow_query_time ：指的并不query_time,而是真正执行时间；即query_time - lock_time; 所以会发生以下问题： 可以通过show processlist;
例：
运行很长时间，却没有记录在表里 ；
会话1：
select * from tabname where a=1 for update;
会话2：
update tabname set a=a+3 where a=1;
会话2会锁上；
会话1释放后，会话2才能执行；
此类情况不会记录到slow 日志中；

COMMAD =SLEEP;
Time 很长；

Q2:MySQL的slow log中Query_time包含了Lock_time吗？

首先先给出结论，Query_time包含了Lock_time

下面给出slow log的头部示例：
#Time: 2019-10-08T08:46:34.635823Z
#执行结束时间戳

User@Host: root[root] @ localhost [] Id: 16

#Query_time: 0.064742 Lock_time: 0.000460 Rows_sent: 1 Rows_examined: 9997**
a.Query_time为SQL的消耗时间
b.Lock_time为锁等待的时间，包括行锁、MDL锁等
c.是否记录slow log的判定条件为SQL的实际执行时间（Query_time - Lock_time）是否超过long_query_time，或者是否开启log_queries_not_using_indexes

查看慢查询SQL方式：
**方式1.**工具mysqldumpslow ：
mysqldumpslow：默认是dump出。/etc/my.cnf
mysqldumpslow --help
–verbose verbose
–debug debug
–help write this text to standard output

-v verbose
-d debug
-s ORDER what to sort by (al, at, ar, c, l, r, t), ‘at’ is default
al: average lock time
ar: average rows sent
at: average query time
c: count
l: lock time
r: rows sent
t: query time
-r reverse the sort order (largest last instead of first)
-t NUM just show the top n queries
-a don’t abstract all numbers to N and strings to ‘S’
-n NUM abstract numbers with at least n digits within names
-g PATTERN grep: only consider stmts that include this string
-h HOSTNAME hostname of db server for -slow.log filename (can be wildcard),
default is '’, i.e. match all
-i NAME name of server instance (if using mysql.server startup script)
-l don’t subtract lock time from total time

mysqldumpslow /mysql/data/slow.log --格式化慢查询日志；
mysqldumpslow slow.log --格式化慢日志；
mysqldumpslow ;有多个options --选项

对于较大的Slow log文件 如何进行询： 对SQL语句进行格式化；
进行tail -n 100000 slowlog >slow.log 因为SQL基本为重复语句，所以采样部分最新的慢日志；
mysqldump slow.log
默认排序at;平均查询时间；
如何证明是否调优有效；
将原来的slowlog 备份下，然后flush slow logs;

**方式2.**存到表;mysql.slow_log;
缺点：
1.性能开销大；
2.备份时，多余备份；所以并不推荐
好处：
是可以通过条件去查询；

配置：
vi /etc/my.cnf
log_output=table;
OUTPUT;不建议table;

重启数据库：
/etc/mysqld restart
show create table slow_log; 可以查看其存储引擎为csv，因为性能差，建议修改为Mysiam，Mysiam性能会好，开销也少很多；
1.set global slow_query_log=0;
set global log_output=table;

2.alter table slow_log engine=Myisam;

Q3: 不用table记录慢日志的原因；
1.记录到表的开销比文件大；
2.备份时，如果没有注意这张表，这张表又很大的话，无用语句备份；
这个表是统常来做慢查询进行定位的，不是用来展示的；可以作多用；

方式3：pt-query-digest

趋势

SYS.STATEMENT_ANALYSIS; SQL分析统计结果，基本所有的SQL都在里面，这个表可以设置多少行；不会很大；有默认的参数可以保证此表的大小；

sys.format_statement();

sys.x$statement_analysis; 不会把时间和存储做一个格式化；但SQL是格式化完的；用来做AWR;
取自performance_scheme;
平均时间的SQL语句；
5.7时，sys库的表都是视图；多数为视图
5.6或5.7后Slowlog没有那么重要；
MYSQL 5.6并没有SYS库；原本是一个开源的项目；+

清理slow_log;
错误：echo ‘’>slow.log; 因mysql 数据库仍在使用，所在空间并不释放 ；
正确：mv slow.log slow_bak.log
命令行执行： flush slow logs;

以上两种方式没有优势之说。开销都不会很大；性能影响也不会很大；

5.6，5.7时slow_log 记录下来，格式化扣；
select * from sys.statement_analysis limit 10\G
X$statement_analysis; 是全局的；
statements_with_full_table_scans 没有索引走全表扫描的；有误统计进来的，如对视图，错误的不重要，执行时间很长的都会被记录进来；
schema_index_status

*************************** 2. row ***************************
query: UPDATE JOB_QRTZ_TRIGGER_REGIS ... = ? ANDregistry_value` = ?
db: job_server
full_scan:
exec_count: 200747
err_count: 0
warn_count: 0
total_latency: 11.35 m
max_latency: 423.33 ms
avg_latency: 3.39 ms
lock_latency: 22.50 s
rows_sent: 0
rows_sent_avg: 0
rows_examined: 679410
rows_examined_avg: 3
rows_affected: 339674
rows_affected_avg: 2
tmp_tables: 0
tmp_disk_tables: 0
rows_sorted: 0
sort_merge_passes: 0
digest: ba89e36d2242610e7585088fd097c5b7
first_seen: 2018-03-12 17:10:33
last_seen: 2018-04-16 13:58:54

慢日志处理流程：
慢日志统计;
慢日志优化；
慢日志清理；