Mysql日志

1. 日志类型

这 6 类日志分别为：

• 慢查询日志： 记录所有执行时间超过long_query_time的所有查询，方便我们对查询进行优化。

• 通用查询日志： 我们对数据库的一些操作，比如use database、use table、select、delect等等。

• 错误日志： 记录MySQL服务的启动、运行或停止MySQL服务时出现的问题，方便我们了解服务器的状态，从而对服务器进行维护。

• 二进制日志： 记录所有更改数据的语句包括DDL、DML，可以用于主从服务器之间的数据同步，以及服务器遇到故障时数据的无损失恢复。

• 中继日志： 用于主从服务器架构中，从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容，来同步主服务器上的操作。

• 数据定义语句日志： 记录数据定义语句执行的元数据操作。

除二进制日志外，其他日志都是文本文件。默认情况下，所有日志创建于MySQL数据目录中。

2. bin log

它记录了数据库所有执行的DDL和DML等数据库更新事件的语句，但是不包含没有修改任何数据的语句（如数据查询语句select、show等）。

binlog主要应用场景：

• 一是用于数据恢复，可以通过bin log文件来查看用户执行了哪些操作，对数据库服务器文件做了哪些修改，然后根据二进制日志文件中的记录来恢复数据库服务器。

• 二是用于数据复制，主从数据的同步

2.1 写入机制

进行了DML或者DDL语句时，先写入内存中的binlog cache中，再刷新到磁盘，和redo log差不多

2.2 binlog与redolog对比

redo log 它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于 InnoDB 存储引擎层产生的。

而 binlog 是逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于MySQL Server 层

虽然它们都属于持久化的保证，但是侧重点不同。

• redo log让InnoDB存储引擎拥有了崩溃恢复能力。
• binlog保证了MySQL集群架构的数据一致性。

2.3 两阶段提交

在执行更新语句过程，会记录redo log与binlog两块日志，以基本的事务为单位，redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入，所以redo log与binlog的写入时机不一样。

当redo log 写入成功而 bin log 还没写入就挂了，就会造成数据不一致。比如：
master将数据按照redo log改了，但是slave在同步master时是按照bin log改，导致数据不一致。

解决：将redo log分为两个阶段 其实就是在写入bin log前面各加一个阶段，确保只有写入bin log才将事务提交，保证数据的一致性。

3. 中继日志

中继日志只在主从服务器架构的从服务器上存在 ，在主从复制需要用到。