2015-04-17 01:23

原创声明：本作品采用知识共享署名-非商业性使用 3.0 版本许可协议进行许可，欢迎转载，演绎，但是必须保留本文的署名（包含链接），且不得用于商业目的。

日志是数据库中的重要组成部分，本文将总结一下MySQL中的那些日志。

MySQL日志类型

MySQL中有如下日志类型：

• 1）错误日志

错误日志记录的是MySQL运行过程中发生的所有错误信息。错误级别包括warning，error，fatal等。 配置方式如下：

1
2

[mysqld]
log-error = ${MYSQL_BASEDIR}/log/mysql.err

• 2）查询日志

查询日志记录所有的连接信息和SQL语句，因此又被称为全日志，包括各种DML/DDL等，常用于审计。可以利用该日志查询某客户端发送的所有SQL。

MySQL按照接收SQL的顺序记录查询日志，也就是说，查询日志中记录的SQL顺序可能与SQL实际执行的顺序不同。这与更新日志和binlog不同，它们在查询执行后，且任何一个锁释放之前记录日志。 配置方式如下：

1
2

[mysqld]
log = ${MYSQL_BASEDIR}/log/mysql.log

• 3）慢查询日志

慢查询日志记录执行时间超过long-query-time的query、没有使用上索引的query等，long-query-time建议设置为1秒。启用慢查询日志可以更好的定位系统瓶颈，有针对的优化SQL，强制开启。配置方式如下：

1
2
3
4

[mysqld]
log-queries-not-using-index
long-query-time  = 1
log-slow-queries = ${MYSQL_BASEDIR}/log/slow.log

• 4）二进制日志（binlog）

binlog记录所有写操作SQL语句，语句以事件形式保存。如load data infile语句，在binlog中记录的事件包括获取文件，装载数据等事件。即，一个SQL被分解为多个事件。

binlog除用于主从复制外，还用于恢复下线的数据库，因为binlog中包含备份后的所有写操作。

binlog的推荐配置方式是：每台server开启log-bin,为避免机器改名引起文件名变化，需在配置文件中指定文件名，格式为mysql-bin[-级别标识]，其中级别标识为可选，主库/主库备机的级别标识为m，一级从库的级别标识为s0，二级从库的级别标识为s1。

1
2
3
4

[mysqld]
log-bin = mysql-bin[-m|-s0|-s1]
expire_logs_days=10
max_binlog_size=100M

下面将重点介绍InnoDB日志。

InnoDB日志

InnoDB的日志（ib_logfile）记录了所有InnoDB表的写操作，用于保证事务的持久性和原子性。该日志并不同于binlog，binlog中记录的是SQL语句，用于主从复制，而InnoDB日志以二进制形式存储，其中记录的信息包括事务id、数据项标识、写操作的新值和旧值等信息，还有诸如事务起止标识等特殊符号。InnoDB采用的是立即修改技术，即，每个事务中的操作都会立即更新内存，因此，为保证事务的原子性，InnoDB记录的是undo日志，为保证数据库的实体完整性，InnoDB记录的是redo日志。

InnoDB日志分为redo日志和undo日志两种，两种日志的区别如下：

undo日志记录如何撤销对数据库的改变，即当执行 rollback 命令时用于回滚事务以恢复数据库从而保证数据库的一致性。

1
2
3
4

（1） 事务开始前向undo日志中记录事务开始标记
（2） 将所有写操作记录到undo日志中
（3） 写日志成功后才能更新内存中的数据库数据
（4） 将事务结束标记写到undo日志中

那么为什么要先写日志再写数据库呢？ 因为日志是顺序写的，非常快。数据，是随机写的，数据如果非常分散。效率会低得一塌糊涂。简单点说。数据可以延后写，日志却不行。因为数据相对于日志，是根本不重要的。它并不决定数据的安全。

redo日志记录的是如何重做某个操作，即当数据库发生故障时（如断电）如何保证数据库的实体完整性，当数据库恢复时会根据redo日志继续执行没有完成的事务。

总结:

1
2
3

1)InnoDB日志的目的是保证事务的持久性。因此日志中需要记录事务中所有的写操作及其他标记，如事务开始、结束标记，检查点标记等。
2)为保证提交的事务最终写到物理磁盘（持久性），因此，数据库系统中采用先写日志原则，即，每个修改要先写日志，再更新缓存中的页。
3)当系统崩溃需要恢复时，MySQL会从日志中寻找检查点而后重做检查点后的所有操作，从而保证持久性，这点是可以借鉴的。