MySQL日志
MySQL中有七种日志文件，分别是
1. 重做日志（redo log）
2. 回滚日志（undo log）
3. 二进制日志（binlog）
4. 错误日志（errorlog）
5. 慢查询日志（slow query log）
6. 常规日志（general log）
7. 中继日志（relay log）
详细介绍
1. 重做日志（redo log）
作用
重做日志（redo log）的作用是确保事务的持久性，防止在发生故障的时间点，尚有脏页未写入磁盘。
在重启 MySQL 服务的时候，根据 redo log 进行重做，从而达到事务的持久性这一特性。
mysql通过redo log 把磁盘的随机IO 变为 日志的顺序IO， 提升写的效率。
内容
物理格式的日志，记录的是物理数据页面修改的信息，其 redo log 是顺序写入 redo log file 的物理文件中去的。
什么时候产生
事务开始之后就产生 redo log，redo log 的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入 redo log 文件中。
什么时候释放
当对应事务的脏页写入到磁盘之后，redo log 的使命也就完成了，重做日志占用的空间就可以重用（被覆盖），redo log是环形写入的。
对应的物理文件
默认情况下，对应的物理文件位于数据库的 data 目录下的 ib_logfile1&ib_logfile2。
关于文件的大小和数量，由以下两个参数配置：
其他
很重要一点，redo log 是什么时候写盘的？前面说了是在事物开始之后逐步写盘的。
之所以说重做日志是在事务开始之后逐步写入重做日志文件，而不一定是事务提交才写入重做日志缓存。
原因就是，重做日志有一个缓存区 Innodb_log_buffer，Innodb_log_buffer 的默认大小为 8M，Innodb 存储引擎先将重做日志写入 innodb_log_buffer 中。
后会通过以下三种方式将 Innodb 日志缓冲区的日志刷新到磁盘(innodb_flush_log_at_trx_commit)：
0： 把日志缓冲写到日志文件， 并且每秒刷新一次， 但是事务提交不做任何操作。
1： 把日志缓冲写到日志文件， 每次事务提交都刷新持久化存储， 这是默认的(最安全的设置)。除非系统做伪刷新。
2： 每次提交把日志写到日志文件， 但是不刷新， InnoDB每一秒做一次刷新， mysql服务异常，可保证数据不丢失。
由此可以看出，重做日志通过不止一种方式写入到磁盘，尤其是对于第一种方式，Innodb_log_buffer 到重做日志文件是 Master Thread 线程的定时任务。因此重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始，逐步开始的。所以可以很好地解释再大的事务提交（commit）的时间也是很短暂的。
2. 回滚日志（undo log）
作用
保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。
内容
逻辑格式的日志，在执行 undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于 redo log 的。
什么时候产生
事务开始之前，将当前时的版本生成 undo log，undo 也会产生 redo 来保证 undo log 的可靠性。
什么时候释放
当事务提交之后，undo log 并不能立马被删除，而是放入待清理的链表，由 purge 线程判断是否由其他事务在使用 undo 段中表的上一个事务之前的版本信息，决定是否可以清理 undo log 的日志空间。
对应的物理文件
MySQL 5.6 之前，undo 表空间位于共享表空间的回滚段中，共享表空间的默认名称是 ibdata，位于数据文件目录中。
MySQL 5.6 之后，undo 表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变 undo log 文件的个数。文件为undo_001等，如果初始化数据库之前没有进行相关配置，那么就无法配置成独立的表空间了。
关于 MySQL 5.7 之后的独立 undo 表空间配置参数如下：
-
innodb_max_undo_log_size=
1073741824 -- 当你打开undo表空间截断功能后，当undo表空间
-
超过innodb_max_undo_log_size设定的大小时，undo表空间就会发生 truncation，innodb_max_undo_log_size默认是
1G
-
innodb_undo_directory=.\ -- undo 独立表空间的存放目录， .\ 表示在数据库的数据目录下
-
innodb_undo_log_encrypt=OFF -- 用于undo redo加密,默认关闭
-
innodb_undo_log_truncate=
ON -- 参数设置为
ON，即开启在线回收（收缩）undo
log日志文件，支持动态设置。
-
innodb_undo_tablespaces=
2 -- 参数必须大于或等于
2，即回收（收缩）一个undo
log日志文件时，要保证另一个undo
log是可用的。
如果 undo 使用的共享表空间，这个共享表空间中又不仅仅是存储了 undo 的信息，共享表空间将默认位于 MySQL 的数据目录下面，其属性由参数 innodb_data_file_path 配置。
其他
undo 是在事务开始之前保存的被修改数据的一个版本，产生 undo 日志的时候，同样会伴随类似于保护事务持久化机制的 redolog 的产生。
默认情况下 undo 文件是保持在共享表空间的，也即 ibdatafile 文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的 undo 信息，全部保存在共享表空间中的。
因此共享表空间可能会变的很大，默认情况下，也就是 undo 日志使用共享表空间的时候，被“撑大”的共享表空间是不会也不能自动收缩的。
因此，MySQL 5.7 之后的“独立 undo 表空间”的配置就显得很有必要了。
3. 二进制日志（binlog）
作用
用于复制，在主从复制中，从库利用主库上的 binlog 进行重播，实现主从同步；用于数据库基于时间点的还原。
内容
逻辑格式的日志，可以简单认为就是执行过的事务中的 SQL 语句，但又不完全是 SQL 语句这么简单。
它包括了执行的 SQL 语句（增删改）反向的信息，也就意味着 delete 对应着 delete 本身和其反向的 insert；update 对应着 update 执行前后的版本的信息；insert 对应着 delete 和 insert 本身的信息。
在使用 MySQLbinlog 解析 binlog 之后一些都会真相大白。因此可以基于 binlog 做到类似于 Oracle 的闪回功能，其实都是依赖于 binlog 中的日志记录。
可以通过指定binlog_format， 设置binlog的记录方式
-
STATEMENT（SBR）
-
每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，
-
减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一
-
致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)
-
-
ROW（RBR）
-
不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况
-
下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤
-
其是
alter
table的时候会让日志暴涨。
-
-
MIXED（MBR）
-
以上两种模式的混合使用，一般的复制使用
STATEMENT模式保存
binlog，对于
STATEMENT模式无法复制的操作
-
使用
ROW模式保存
binlog，MySQL会根据执行的
SQL语句选择日志保存方式。
什么时候产生
事务提交的时候，一次性将事务中的 SQL 语句（一个事物可能对应多个 SQL 语句）按照一定的格式记录到 binlog 中。
这里与 redo log 很明显的差异就是 redo log 并不一定是在事务提交的时候刷新到磁盘，redo log 是在事务开始之后就开始逐步写入磁盘。
因此对于事务的提交，即便是较大的事务，提交（commit）都是很快的，但是在开启了 bin_log 的情况下，对于较大事务的提交，可能会变得比较慢一些。
这是因为 binlog 是在事务提交的时候一次性写入造成的，这些可以通过测试验证。
什么时候释放
binlog 默认是保持时间由参数 expire_logs_days 配置，也就是说对于非活动的日志文件，在生成时间超过 expire_logs_days 配置的天数之后，会被自动删除。
对应的物理文件
-
log_bin： 开启状态， 建议打开设为 ON
-
log_bin_basename： 文件路径及名前缀
-
log_bin_index： binlog文件index文件
-
log_bin_trust_function_creators： 当二进制日志启用后，这个变量就会启用。它控制是否可以信任存
-
储函数创建者，不会创建写入二进制日志引起不安全事件的存储函数。
-
如果设置为0（默认值），用户不得创建或修改存储函数，除非它们具有除
CREATE ROUTINE或
ALTER ROUTINE特权之外的SUPER权限。
-
设置为
0还强制使用
DETERMINISTIC特性或
READS
SQL
DATA或
NO
SQL特性声明函数的限制。
-
如果变量设置为
1，MySQL不会对创建存储函数实施这些限制。 此变量也适用于触发器的创建。
-
log_bin_use_v1_row_events： 默认是
0，如果使用
1是使用Version1的格式，mysql5
.5可以认出来的形式，如果
0是
5.6
.6后使用的version2格式。
其他
二进制日志的作用之一是还原数据库
redo log 是保证事务的持久性的，是事务层面的；binlog 作为还原的功能，是数据库层面的， 两者日志产生的时间、可以释放的时间，在可释放的情况下清理机制，都是完全不同的。
恢复数据时候的效率，基于物理日志的 redo log 恢复数据的效率要高于语句逻辑日志的 binlog
MySQL 通过两阶段提交过程来完成事务的一致性的，也即 redo log 和 binlog 的一致性，理论上是先写 redo log，再写 binlog，两个日志都提交成功（刷入磁盘），事务才算真正的完成。
4. 错误日志（errorlog）
错误日志是一个文本文件。
错误日志主要记录
服务器启动和关闭过程中的信息
服务器运行过程中的错误信息
事件调度器运行一个时间是产生的信息
在从服务器上启动从服务器进程是产生的信息
指定 log_error， 可以指定错误日志的文件
错误日志是一个标准的日志文本文件， 记录错误的详细信息
5. 慢查询日志（slow query log）
当语句执行时间较长时，通过日志的方式进行记录，这种方式就是慢查询的日志。
缺省情况下慢查询日志记录在 hostname-slow.log为慢查询日志文件名，存放到数据目录，同时缺省情况下未开启慢查询日志。
缺省情况下数据库相关管理型SQL(比如OPTIMIZE TABLE、ANALYZE TABLE和ALTER TABLE)不会被记录到日志。
-
slow_query_log=ON
-- 是否已经开启慢查询，临时开启慢查询日志：set global slow_query_log = ON;
-
slow_query_log_file=slow.log
-- 指定慢查询日志文件的路径和名字或者表名，可使用绝对路径指定；
-
默认值是'主机名_slow.log'，位于datadir目录
-
long_query_time=2
-- 超过多少秒的查询就写入日志，
-
临时设置慢查询时间临界点：
set long_query_time =
1;默认时间阈值为10s
-
log_queries_not_using_indexes ：如果值设置为ON，则会记录所有没有利用索引的查询(性能优化时开启此项,平时不要开启)
-
-
min_examined_row_limit=100
-- SQL语句扫描的行数少于设定值的语句不会被记录到慢查询日志，
-
即使这个语句执行时间超过了long_query_time的阈值，默认为0
-
log_throttle_queries_not_using_indexes=10
-- 设定每分钟记录到日志的未使用索引的语句数目，
-
超过这个数目后只记录语句数量和花费的总时间
-
log_output=FILE,TABLE
-- 日志文件记录方式
-
log_slow_admin_statements=ON
-- 记录执行缓慢的管理SQL，如alter table,analyze table,
-
check
table,
create
index,
drop
index,
optimize
table,
repair
table等
-
log_slow_slave_statements=
ON
-- 记录从库上执行的慢查询语句， 默认为 OFF
-
log_timestamps=
system
-- 版本新增时间戳所属时区参数，默认记录UTC时区的时间戳到慢查询日志，最好修改为记录系统时区
记录的文件是一个标准的日志文本文件， 里面含有线程Id， timestamp，具体的SQL，user， 执行时长以及执行信息。
记录时间
DDL语句: exec时间
DML语句: select从等待锁开始计时，insert只记录执行时间
6. 常规日志、通用查询、全量日志（general log）
开启后，记录client和数据库的所有请求
-
general_log=OFF
-- 默认关闭， 打开设置为off即可
-
general_log_file=hostname.log
-- 不指定路径存储到datadir下，如果不指定名字是 '主机名.log'
-
log_output=FILE,TABLE
-- 日志文件记录方式
记录的文件是一个标准的日志文本文件， 里面含有Time，线程Id，Command类型，Argument(具体的操作语句)。
7. 中继日志（relay log）
中继日志来自Master的二进制日志，IO线程从Master读取，然后写入本地的一类日志，类似于binary log。作为SQL线程的输入，中继日志中的事件将通过SQL线程来重演，从而实现复制。
常用设置
-
max_relay_log_size=
0; -- 标记relay
log 允许的最大值，如果该值为
0，
-
则默认值为max_binlog_size(
1G)；如果不为
0，则max_relay_log_size则为最大的relay_log文件大小
-
relay_log=; -- 定义relay_log的位置和名称，如果值为空，
-
则默认位置在数据文件的目录（datadir），文件名为host_name-relay-bin.nnnnnn
-
relay_log_basename=; -- 定义relay_log的位置，如果值为空，则默认位置在数据文件的目录（datadir）
-
relay_log_index=; -- 定义relay_log索引的位置和名称，如果值为空，
-
则默认位置在数据文件的目录（datadir），文件名为host_name-relay-bin.idx
-
relay_log_info_file=relay-
log.info; -- 设置relay-
log.info的位置和名称（relay-
log.info记录MASTER的binary_log的恢复位置和relay_log的位置）
-
relay_log_info_repository=FILE; -- 日志文件记录方式，默认为FILE
-
relay_log_purge=
ON; -- 是否自动清空不再需要中继日志时。默认值为
1(启用)。
-
relay_log_recovery=OFF; -- 当slave从库宕机后，假如relay-
log损坏了，导致一部分中继日志没有处理，
-
则自动放弃所有未执行的relay-
log，并且重新从master上获取日志，这样就保证了relay-
log的完整性。
-
默认情况下该功能是关闭的，将relay_log_recovery的值设置为
1时，可在slave从库上开启该功能，建议开启。
-
relay_log_space_limit=
0; -- 防止中继日志写满磁盘，这里设置中继日志最大限额。
-
但此设置存在主库崩溃，从库中继日志不全的情况，不到万不得已，不推荐使用；
-
sync_relay_log=
10000; -- 这个参数和 sync_binlog 是一样的， 建议采用默认值
-
当设置等于
0，表示MySQL不控制
log的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。
-
因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。
-
当设置为
1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay
log中继日志里，
-
这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但大事务时会造成大量的磁盘IO。
-
当设置为大于
0时，slave的I/O线程接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay
log中继日志里，
-
值设置的越大，造成的磁盘IO越小，但是当出现异常，丢失的事务越多。
-
sync_relay_log_info=
10000; -- 这个参数和 sync_binlog 是一样的， 建议采用默认值
-
当设置等于
0，表示MySQL不控制
log的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。
-
因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。
-
当设置为
1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay
log中继日志里，
-
这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但大事务时会造成大量的磁盘IO。
-
当设置为大于
0时，slave的I/O线程接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay
log中继日志里，
-
值设置的越大，造成的磁盘IO越小，但是当出现异常，丢失的事务越多。
3202
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
