MySQL三种重要日志

日志是MySQL的重要组成部分，其中对于开发而言不得不关注三种重要的日志，分别是二进制日志（bin log）、事务日志（redo log、undo log）。接下来详细介绍这三种日志。

binlog叫做二进制日志，主要是用于记录MySQL表的逻辑变化过程。在实际应用过程中，通常被用于主从复制和数据恢复。

事务执行过程中，会先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。

事务提交后的写入只是写入到文件系统的page cache，并没有把数据持久化到磁盘。持久化磁盘由 *** 作系统决定调用fsync。

MySQL提供了配置决定fsync的时机，当sync_binlog=0的时候，每次提交事务只写入page cache，不执行fsync。当sync_binlog=1的时候，表示每次提交事务都会执行fsync。当sync_binlog = N的时候，每次提交事务都写入page cache，累计多个事务才进行fsync。

显然，当sync_binlog = 1的时候，binlog日志不会丢失。当sync_binlog = N的时候，如果发生异常重启，会丢失N个事务的binlog日志。

STATEMENT

记录数据 *** 作的原始SQL，可能引发主库备库因索引选择不一致，导致数据执行结果不一致。

ROW

ROW基于行复制，只记录哪条数据被修改.缺点：占空间。比如DELETE 语句，对于STATEMENT只占用1条SQL。而ROW格式则需要把所有记录的数据记录下来。

MIXED

对于可能引发主备不一致的命令使用ROW格式，否则使用STATEMTNT

对于每一次更新 *** 作，MySQL都需要写入磁盘，然后需要找到对应那条记录并更新。IO成本较高和查找成本都很高。为了提高性能，MySQL会将更新 *** 作写入redo log，并更新内存。INNODB引擎会在适当的时候将 *** 作记录更新到磁盘。

[图片上传失败...(image-c6a1f2-1627716309698)]

undo log主要是记录了数据的逻辑变化，比如对应一条insear语句，undo log会记录一条delete语方便回退到更新前的值。

时刻A发生故障的话，由于binlog未写入，redo log回滚数据，两个日志数据是一致的。

时刻B发生故障，则需要判断binlog是否完整来决定如何恢复。

redo log和bin log的区别？

为什么redo log crash-safe，而bin log不可以？

mysql有以下几种日志：  

错误日志：     -log-err

查询日志：     -log

慢查询日志:   -log-slow-queries

更新日志:     -log-update

二进制日志： -log-bin

是否启用了日志 

mysql>show variables like 'log_%'

怎样知道当前的日志 

mysql> show master status

显示二进制日志数目 

mysql> show master logs

看二进制日志文件用mysqlbinlog 

shell>mysqlbinlog mail-bin.000001

或者

shell>mysqlbinlog mail-bin.000001 | tail

在配置文件中指定log的输出位置. 

Windows：Windows 的配置文件为 my.ini，一般在 MySQL 的安装目录下或者 c:\Windows 下。

Linux：Linux 的配置文件为 my.cnf ，一般在 /etc 下。 

windows下

# 在[mysqld] 中输入  

#log  

log-error="E:/PROGRA~1/EASYPH~1.0B1/mysql/logs/error.log"  

log="E:/PROGRA~1/EASYPH~1.0B1/mysql/logs/mysql.log"  

long_query_time=2  

log-slow-queries= "E:/PROGRA~1/EASYPH~1.0B1/mysql/logs/slowquery.log"

Linux下

# 在[mysqld] 中输入  

#log  

log-error=/usr/local/mysql/log/error.log  

log=/usr/local/mysql/log/mysql.log  

long_query_time=2  

log-slow-queries= /usr/local/mysql/log/slowquery.log

有时候我们会不小心对一个大表进行了 update，比如说写错了 where 条件......

此时，如果 kill 掉 update 线程，那回滚 undo log 需要不少时间。如果放置不管，也不知道 update 会持续多久。

那我们能知道 update 的进度么？

实验

我们先创建一个测试数据库：

快速创建一些数据：

连续执行同样的 SQL 数次，就可以快速构造千万级别的数据：

查看一下总的行数：

我们来释放一个大的 update：

然后另起一个 session，观察 performance_schema 中的信息：

可以看到，performance_schema 会列出当前 SQL 从引擎获取的行数。

等 SQL 结束后，我们看一下 update 从引擎总共获取了多少行：

可以看到该 update 从引擎总共获取的行数是表大小的两倍，那我们可以估算：update 的进度 = (rows_examined) / (2 * 表行数)