大概有错误日志，查询日志，慢查询日志，事务日志，二进制日志，中继日志

一、错误日志

错误日志默认是开启且无法禁止的，在数据库的数据文件目录，hostname.err文件，可以配置错误的日志存储位置和日志级别。

1.存放服务器启动关闭过程中的信息。（未必是错误）

2.存放运行过程中的错误信息。

3.一旦mysql调度启动一个计划任务的时候，它也会将相关信息记录在错误日志中

4.从服务器启动的日志也会存入错误日志。

二、查询日志

general log(通用日志)，记录了数据库执行的所有命令，不论语句是否正确，插入、更新、删除操作都会进行查询操作。

在并发场景下，查询日志可能会非常多，如果都记录下来可能会导致IO压力非常大，所以建议在调试场景下才开启查询日志。

general_log可以控制是否开启，general_log_file控制存放位置。0

三、慢查询日志

慢查询会导致CPU，IOPS，内存消耗过高，开启慢查询日志记录超过指定时间的查询，默认情况下是不开启的，需要手动开启。

四、事务日志

数据库事有缓存存在的，因为每次读写都从物理磁盘操作性能会非常低下，数据库缓存是data buffer，日志（redo）缓存是log buffer。因为有缓存的存在，所以就很难保证缓存数据与磁盘数据的一致性。

为了防止内存中的缓存数据丢失导致数据不一致的问题，InnoDB的事务重做日志redo log和回滚日志undo log。

InnoDB通过force log at commit机制实现事务的持久性，在提交事务之前必须将所有的事务日志持久化到磁盘中的redo log file和undo log file中。

1.redo log日志（物理日志 先写日志，再写磁盘）innodb 独有的

redo log 分为两部分，一部分是在内存中的日志缓冲，是容易丢失的一部分，另一个部分就是磁盘上的重做日志文件，并且事务的追加是顺序追加的（磁盘的顺序写比内存写性能差不了太多）。

使用这种重做日志可以减小提交事务时的开销，因为日志中记录了事务的操作，不用立刻将脏块刷新到磁盘中（随机IO非常昂贵），即时断电了也可以通过InnoDB的重做日志来恢复数据。

为了确保每次日志都可以写入到日志文件中，每次在log buffer写入日志文件中都会调用一次fsync()系统调用。中间其实还有一层OS Buffer，是操作系统的缓存区，只有当缓存区达到一定大小，或者使用fsync()系统调用可以立即让OS Buffer中的数据写入磁盘中。

innodb_flush_log_at_trx_commit 参数可以设置刷入磁盘的策略。

0：事务提交时不会将log buffer中的数据写入os buffer,而是每秒写入一次OS buffer 并调用fsync()写入磁盘，系统崩溃会损失一秒的数据。

1：每次提交都会写入一次OS buffer 并调用fsync()写入磁盘，IO性能相对较差。

2：每次提交都仅写入到os buffer，然后是每秒调用fsync()将os buffer中的日志写入到log file on disk。

为了保证主从复制，保证事务持久性和一致性就配置为1吧。

2.undo log日志（逻辑日志）

有两个作用，提供回滚和MVCC服务。undo log属于逻辑日志，redo log 属于物理日志

Undo log中存放着老版本的数据，当一个事务想读取数据行的时候，发现不可见，就会顺着Undo log链寻找满足其可见性的数据版本。

1.insert undo log：事务插入数据产生的日志，只在回滚的时候使用，在事务提交后就可以删除。

2.update undo log：事务对记录进行更新或者删除操作的时候产生的undo log ，不仅仅回滚要用，而且快照读取也需要，只要当数据库使用的快照不涉及该日志记录才会被删除（Purge线程删除）。

五、二进制日志（binary log）Server实现的，所有引擎都可用

主要记录数据库表的结构变化，以及表数据修改，的所有操作。并且记录语句发生的时间，执行时长，操作数据。但是不记录select、show这些不对数据进行修改的命令。

binlog的作用：

1.恢复：某些数据的恢复需要二进制日志。

2.复制：可以通过复制和执行二进制文件使得一台远程的MySQL数据库和一台mysql服务器进行数据同步。

3.审计：可以通过二进制日志来判断数据库是否被进行了注入攻击。

binlog对数据库的崩溃恢复也有重要的作用，为了保证binlog和redolog的一致性，mysql将事务的提交分为两个阶段，准备提交和已经提交的阶段。

准备提交：如果这个时候binlog中存在事务，就进行提交操作，如果binlog中不存在，就进行回滚操作，保证了主从同步。

binlog默认是关闭的，可以通过配置文件log-bin = [base-name]来开启binlog。

binlog有三种存储格式：

1.STATEMENT：存储原生的sql语句，优点是更加节约磁盘空间，缺点是两个数据库执行结果可能不同，比如当前时间。另外触发器和储存过程也会出现问题，再就是复制的sql语句是需要串行化执行的，需要额外的配置，如InnoDB的next-key锁。

2.ROW（推荐使用）：基于行来复制，会将实际数据记录到二进制文件中，几乎没有基于行处理不了的场景，缺点就是文件可能会很大，但是优点已经可以弥补它的缺点了。

3.MIXED：是MySQL默认的二进制日志文件的方式，默认使用sql语句，当发现无法精确的复制的时候就会采用基于行的方法复制。

六、中继日志（relay log）

relay log是复制过程中产生的日志，很多方面都跟binary log差不多，区别是: relay log是从库服务器I/O线程将主库服务器的二进制日志读取过来记录到从库服务器本地文件，然后从库的SQL线程会读取relay-log日志的内容并应用到从库服务器上。

两种日志特点对比：

1.redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。

2.redo log是物理日志，记录的是"在某个数据页上做了什么修改"；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如"给ID=2这一行的c字段加1 "。

3.redo log是循环写的，空间固定会用完；binlog是可以追加写入的。"追加写"是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志