mysql 日志

错误日志：

错误日志对mysql的启动，运行，关闭进行了记录。该文件不仅记录了所有的错误信息，

也记录一些警告的信息或正确的信息。用户可以通过命令:show variables like 'log_error'

来定位该文件，如：

--------------------------------------------------------------------------------------------------------------

慢查询日志：

使用命令 show variables like '%slow%' 查看慢查询的日志信息，如：

log_slow_queries：表示慢查询日志已开启（默认是不开始的，需用户手动开启）

slow_launch_time：该值跟慢查询没有多大关系，它表示的是thread create的阈值

slow_query_log_file：慢查询日志文件的存放路径

现在我们看到慢查询已经开启了，那么来查看一下查询超过多少时间，才会记录日志：

通过命令 show variables like 'long_query_time' 看到，执行超过0.0001秒时，才会被记录；

另一个和慢查询日志有关的参数是log_queries_not_using_indexes,它表示如果语句没有

使用索引时，是否也同样记录到慢查询日志中，首先得确认该设置是否已经启用：

其Value值为ON，说明已开启了（默认是不开启的，需手动开启），最后我们找到慢查询日志

文件，来查看下执行最慢的3条SQL：./mysqldumpslow -s al -t 3 /data0/mysql/3306/slow_log.log

mysql也可将慢查询日志记录放入一张表中，慢查询表在mysql架构下，名为slow_log ；首先还是得先通过

如果要设置为保存表中，使用命令：set global log_output='TABLE';

最后贴一下mysql配置文件(my.cnf)中慢查询日志的设置:

log_queries_not_using_indexes：表示未用到索引的SQL，超过执行时间，每分钟只记录1次，设置为0,表示没有限制。

-------------------------------------------------------------------------------------------------------

查询日志：

查询日志记录了所有对mysql数据库请求的信息，无论这些请求是否得到了正确的执行。

开启mysql查询日志：

查看是否已开启：

查看查询日志内容：

-------------------------------------------------------------------------------------------------------

二进制日志（binary log）：

二进制日志记录了对mysql数据库执行的更改的所有操作，但不包括SELECT和SHOW这类操作，因为这类操作

对数据本身并没有修改。如果用户想记录SELECT和SHOW操作，那只能使用查询日志。此外，二进制日志还包括

了执行数据库更改操作的时间等其他额外信息。总的来说，二进制日志主要有以下几个作用：

• 恢复：通过二进制日志可以恢复全部数据，也能进行point-in-time的恢复；
• 复制：其原理和恢复类似，通过复制和执行二进制日志使多台数据库进行数据实时同步；
• 审计：用户可以通过二进制日志中的信息来判断是否有对数据库进行注入的攻击；

二进制日志在默认情况下是未开启的，需要手动开启。 开启二进制的确会影响性能，但是性能的损失十分有限，

根据 MYSQL官方测试表示，开启二进制日志使使性能下降1%，但考虑到可以使用复制和point-in-time的恢复，

这些性能损失绝对是可以接受的。

通过配置参数log-bin=[name]可以启动二进制日志，如： log-bin = /data0/mysql/3306/binlog/binlog

然后来查看下二进制日志是否已开启：

二进制日志开启后，所有的更改操作都会记录到二进制文件中，以下是所有的二进制文件：

binlog.index为二进制的索引文件，用来存储产生的二进制的日志序号。

下列配置文件的参数影响着二进制日志记录的信息和行为：

• max_binlog_size：指定了单个二进制文件的最大值，如果超过该值，则产生新的二进制文件，后缀名+1
• binglog_cache_size：当使用事务的存储引擎时，所有未提交的更改会写入到二进制缓冲，该值为缓冲大小
• sync_binlog
• binlog_do-db
• binlog-ignore-db
• log-slave-update
• binlog_format：记录二进制日志的格式，该参数可设置的值有：STATEMENT,ROW,MIXED(默认)

--------------------------------------------------------------------------------------------------------------------------------------------

重做日志（InnoDB）：

在默认情况下，在Innodb存储引擎的数据目录下会有两个名为ib_logile0和ib_logfile1的文件，该文件就是重做日志

文件(redo log file)，它们记录了对于innodb存储引擎的事务日志。重做日志用于恢复数据库或者主机发生异常时

（如断电啥的），通过重做日志恢复到异常前的时刻，以此来保证数据的完整性。

每个innodb至少有一个重做日志文件组，每个组下至少有2个重复日志文件，如默认的ib_logile0和ib_logfile1。

为了得到更高的可靠性，用户可以设置多个镜像日志组，将不用的文件组放在不同的磁盘上，以此来提高重做日志

的高可用性。下列参数影响着重做日志文件的属性：

• innodb_log_file_size：指定每个重做日志的大小
• innodb_log_file_in_group：指定日志文件组中重做日志文件的数量，默认为2
• innodb_mirrored_log_group：指定了日志镜像文件组的数量，默认为1
• innodb_log_group_home_dir：指定日志文件组所在的路径，默认为./

innodb_flush_log_at_trx_commit：该参数控制事务在提交时，处理重做日志的方式，有效值有：0,1,2

0：代表当前事务提交时，不降事务的重做日志写入到磁盘上的日志文件，而是等待主线程每秒的刷新。

1：表示在执行提交时，将重做日志缓冲同步写到磁盘，即伴有fsync的调用。

2：表示将重做日志异步写到磁盘，因为不能完全保证在执行commit时肯定会写入到重做日志文件。

总结：为了保证食物的ACID中的持久性，必须将innodb_flush_log_at_trx_commit参数设置为1，也就是每当事务

提交时，就必须确保事务都已经写入重做日志文件。那么当数据库意外发生宕机时，可以通过重做日志文件恢复。