由于打申请用查问日志是记载用户的一切操作，在消费环境中这个日志的量是十分大的，所以普通状况下都是不关上的，myslq自动的该日志性能也是封锁的，在不凡状况下才启动关上。

日志类型：

有几个不同的日志文件，可以协助你找出mysqld外部出现的事件：

日志文件	记入文件中的消息类型
失误日志	记载启动、运转或中止时出现的疑问
查问日志	记载建设的客户端衔接和口头的语句
二进制日志	记载一切更改数据的语句。关键用于复制和即时点复原
慢日志	记载一切口头时期超越long_query_time秒的一切查问或不经常使用索引的查问
事务日志	记载InnoDB等允许事务的存储引擎口头事务时发生的日志

1.启动慢查问日志：

假设启用了slow_query_log=ON选项，就会记载口头时期超越long_query_time(自动10s)的查问(初使表锁定的时期不算作口头时期)。日志记载文件为slow_query_log_file[=file_name]，假设没有给出file_name值，默以为主机名，后缀为-slow.log。假设给出了文件名，但不是相对门路名，文件则写入数据目录。

这个可以在调试mysql性能的时刻启用,可以找出是哪个sql指令最糜费时期。消费环境中倡导封锁。

2.消费环境中封锁通用查问日志：

由于打申请用查问日志是记载用户的一切操作，在消费环境中这个日志的量是十分大的，所以普通状况下都是不关上的，myslq自动的该日志性能也是封锁的，在不凡状况下才启动关上。

普通只要在开发测试环境中，为了定位某些性能详细经常使用了哪些SQL语句的时刻，才会在短时期段内关上该日志来做相应的剖析。

mysql>setglobalgeneral_log=1;#1：启动通用查问日志，0：封锁通用查问日志mysql>showglobalvariableslike‘%general_log%’;+------------------+----------------------------+|Variable_name|Value|+------------------+----------------------------+|general_log|ON|#能否启用了通用查问日志|general_log_file|/var/run/mysqld/mysqld.log|#日志门路+------------------+----------------------------+2rowsinset(0.00sec)

3.活期备份二进制日志和sql数据：

【本地一份，远程日志主机一份，存储主机一份】

在my.cnf中log-bin=[filename]是启用二进制日志，自动以[filename].000001往上记载的，从启用log-bin之后此时最好用mysqldump保留以后的mysql某个库的数据，由于二进制日志只是记载了从如今起到最近一次性mysql当机重启中的一切sql语句，mysql就会开局记载每一个sql语句，一旦mysql因各种要素须要重启，则会发生新的二进制日志，000001的后缀名会始终往上自加。若是在mysql当机时期mysql的数据受到了破坏(如磁盘损坏)，之前的数据所有都被破坏了，这时刻这个备份战略就可以帮你拯救损失。你可以从二进制日志中复原从开局到最近一次性mysql重启这段时期的数据。【二进制日志中记载的是每一个sql语句，可以用mysqlbinlog[filename]检查日志内容】

4.sync_binlog全局变量的取值必定要适合：

自动状况下，并不是每次写入时都将二进制日志与硬盘同步。因此假设操作系统或机器(不只仅是MySQL主机)解体，有或许二进制日志中最后的语句失落了。要想防止这种状况，你可以经常使用sync_binlog全局变量(1是最安保的值，但也是最慢的)，使二进制日志在每N次二进制日志写入后与硬盘同步。对非事务表的更新口头终了后立刻保留到二进制日志中。

sync_binlog：这个参数是关于MySQL系统来说是至关关键的，他不只影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。

关于sync_binlog参数的各种设置的说明如下：sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的消息到磁盘，而让Filesystem自行选择什么时刻来做同步，或许cache满了之后才同步到磁盘。

sync_binlog=n，当每启动n次事务提交之后，MySQL将启动一次性fsync之类的磁盘同步指令来将binlog_cache中的数据强迫写入磁盘。

在MySQL中系统自动的设置是sync_binlog=0，也就是不做任何强迫性的磁盘刷新指令，这时刻的性能是最好的，然而危险也是最大的。由于一旦系统crash，在binlog_cache中的一切binlog消息都会被失落。而当设置为1的时刻，是最安保然而性能损耗最大的设置。由于当设置为1的时刻，即使系统crash，也最多失落binlog_cache中未成功的一个事务，对实践数据没有任何实质性影响。从以往阅历和相关测试来看,关于高并发事务的系统来说,sync_binlog设置为0和设置为1的系统写入性能差距或许高达5倍甚至更多。

5.假设数据库有很多的事务型操作，则倡导把二进制日志的回滚下限设置大一些：

关于事务表，例如BDB或InnoDB表，一切更改表的更新(UPDATE、DELETE或INSERT)被缓存起来，直到主机接纳到COMMIT语句。在该点，口头完COMMIT之前，mysqld将整个事务写入二进制日志。

当处置事务的线程启动时，它为缓冲查问调配binlogcachesize大小的内存。假设语句大于该值，线程则关上暂时文件来保留事务所以假设bunlogcachesize足够大，就防止了过多的磁盘的I/O操作,可以把数据所有缓存在内存中。

线程完结后暂时文件被删除。max_binlog_cache_size和binlog_cache_size相对应，然而所代表的是binlog能够经常使用的最大cache内存大小。当咱们口头多语句事务的时刻，max_binlog_cache_size假设不够大的话，系统或许会报出"Multi-statementtransactionrequiredmorethanmax_binlog_cache_sizebytesofstorage的失误。所以最好也把maxbinlogcache_size也调大些(详细多大看你的主机了)。

6.尽量把maxbinlogsize设置大些

Binlog日志最大值，普通来说设置为512M或许1G，但不能超越1G。该大小并不能十分严厉控制Binlog大小，尤其是当抵达Binlog比拟接近尾部而又遇到一个较小事务的时刻，系统为了保证事务的完整性，无法能做切换日志的举措，只能将该事务的一切SQL都记载进入以后日志，直到该事务完结。

7.上方是mysql环境的状况：

mysql>showvariableslike‘%binlog%’;+--------------------------------+------------+|Variable_name|Value|+--------------------------------+------------+|binlog_cache_size|1048576||innodb_locks_unsafe_for_binlog|OFF||max_binlog_cache_size|4294967295||max_binlog_size|1073741824||sync_binlog|0|+--------------------------------+------------+

地址：

---

mysql 很多慢日志，怎么解决

这是一个慢查询日志的展示工具，能够帮助 DBA 或者开发人员分析数据库的性能问题，给出全面的数据摆脱直接查看 slow-log。QAN（Query Analytics）

PMM 目前有 2 个版本，但是对于 QAN 来说其大致由三部分组成：

QAN-Agent（client）：负责采集 slow-log 的数据并上报到服务端

QAN-API（server）：负责存储采集的数据，并对外提供查询接口

QAN-APP：专门用来展示慢查询数据的 grafana 第三方插件

1. 数据流转

slow-log --> QAN-Agent --> QAN-API <--> QAN-APP（grafana）

2. pmm1 架构图

3. pmm2 架构图

怎么进入mysql日志mysql日志进入方法

1、首先找到MySQL的配置文件，在[mysqld]下添加

2、general_log_file=~/

3、同时，登录MySQLconsole中设置打开log

4、mysql-uroot

5、>SETglobalgeneral_log=1;

6、重启MySQL之后就可以在当前用户的HOME目录中通过查看SQL日志了。