mysql中日志主要分为以下几种：错误日志、慢查询日志、二进制日志和事务日志。

1. 错误日志

记录mysql启动时发生的错误信息，没什么好说的，因为工作中不常用。

2. 慢查询日志

这是mysql维护的一个日志文件，它用来自动记录执行时间超过某个阈值的SQL语句，通过查看这个日志，我们一般可以发现运行的慢SQL，

这个阈值通过long_query_time 变量可以控制，默认是10,我们可以使用如下命令查看和修改

show variables like 'long_query_time' ;

set global long_query_time = 1;

一般来说，并发量高的业务的SQL都需要走索引，正常走索引的查询SQL会控制在几十ms以内，如果表数据量很小的话，几ms就够了，所以long_query_time设置的小一点比较好，例如200ms。

当然，mysql记录这个日志肯定是需要耗费一定的性能的，所以它设置了一个变量slow_query_log来控制是否记录慢查询日志(默认是关闭的)，个人感觉不会造成多大的压力，如果你的工程没有在业务层做sql监控的话，这个还是很有必要的。

3. binlog日志(归档日志)

这个大家应该听的比较多，数据备份恢复、主从同步等之类的都是依赖这个实现的，有些还要监听binlog做一些数据同步，例如同步到es中等等。

那么binlog到底是什么东西呢？

binlog又叫二进制日志文件，它会将mysql中所有修改数据库数据的请求以二进制的形式记录到日志文件中，所以像一些select就不会存储在这里。binlog是Server层的日志，也就是所有存储引擎(innodb、myisam等)都会有binlog日志。

一般来说,binlog日志是不会开启的，开启之后性能会有 1% 的下降。想要开启这个日志的话，我们可以在my.ini中添加如下配置

log-bin = [ on | filename ] ; 【filename表示生成的日志文件名字】

例如：log-bin = mysql-bin

binlog 是以二进制形式存储的逻辑日志，每次有需要记录的日志，就会追加在文件的末尾，一般，binlog有两种模式：

statement 格式:记录的是执行的sql

row 格式：记录的是sql影响的行的内容，记录两条，更新前和更新后的。

4.事务日志

事务日志是innodb独有的日志文件：包括redo log 和 undo log。它是用来做崩溃恢复和事务回滚的。

redo Log : 是物理日志，记录的是某个数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。

undo Log : 是逻辑日志，根据每行记录进行记录，用来回滚到某个版本，它和redo log正相反，记录某数据被修改前的值，可以用来在事务失败时进行rollback。

重点可以说一下redo log,它的空间是固定大小的，在逻辑上是一个闭环，从头开始写，写到末尾之后又从头开始写，所以，redo log 维护了两个指针位置：

write point :当前可写的位置，不断写不断往后移动

check point当前要擦除的位置，擦了之后往后移动。

从这里我们就可以看出redo log 有两个特性：顺序写和批量提交。

说了这么多，我们可以来用一个简单的例子来大致看一下这些日志记录的 顺序与区别：(假设binlog 是statement模式的)。

例如我们要执行：

update tableA set a = 1 where id = 1000000

语句经过优化器生成执行计划，然后发现Id是主键索引，可以选择Id索引。

执行器拿到这个sql后，调用存储引擎接口，去索引树上找id = 1 的数据，如果正好在内存中有，则直接返回数据；如果没有，则去磁盘中把对应的数据页读到内存中返回(可能不止一次IO操作)；

执行器拿到数据之后，将 a 赋值为1，然后再调用引擎接口写入这个修改后数据。

引擎收到更新请求，生成一个全局唯一的事务ID(XID)，然后将这个记录更新到缓存，然后记录redo log (包含XID)和 undo log, 此时redo log 状态变为 prepare 状态，并返回成功给执行器。

执行器收到成功之后，记录这个操作的binlog 日志(其中包含XID)

执行器调用引擎的commit接口，将redo log 改成commit状态，结束。

待续......