共计 934 个字符，预计需要花费 3 分钟才能阅读完成。
要了解数据库的日志系统首先得知道其存在的必要性：
数据库事务的 ACID 中的 Durability- 持久性就是依靠日志系统来实现的
日志模块：redo-log（InnoDB 特有）
当数据库引擎 InnoDB 从服务层接收到一条更新语句，InnoDB 引擎就会先把记录写到 redo log 中并更新到内存中（效率非常高），并在空闲的时候将数据写入到磁盘中（此时才是实际更新）
值得注意的是 InnoDB 的 redo-log 记录的数据有限，当超过大小之后会先等日志写入到磁盘释放出一部分空间后才能继续写入到 redo-log 日志文件中
虽然 redo-log 记录的数据有限但依旧可以保留大量数据，当数据库发生异常重启时，依旧可以通过 redo-log 恢复数据而不用担心数据写入磁盘过程中发生异常而产生的数据丢失
日志模块：bin-log（存在于 server 层 MySQL 自带）
最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM。
bin-log 是记录着 mysql 所有事件的操作，可以通过 bin-log 做完整恢复，因此当你不小心删库了也可以通过 bin-log 日志系统恢复数据，可以基于时间点恢复也可以基于位置恢复。你也可以利用二进制日期进行远程复制，通过主机上的二进制日志文件，将数据更改同步到备机。
值得注意的是 MyISAM 的 bin-log 日志系统并没有 crash-safe 能力，这也是 InnoDB 引入 redo-log 日志系统的原因。
bin-log 日志文件没有大小限制，是可以线性增长的。当一个文件满了，会重新创建一个日志文件。一般情况下我们安装 mysql 之后 binary log 二进制日志并没有开启，需要我们自行开启。（具体开启语句以及恢复数据语句可以自行百度查到）
日志的两阶段提交
上面我们讲了数据库存在的两种日志而其中一种日志不具有 crash-safe 能力，那么问题来了：当发生数据库异常重启时，redo-log 记录的数据比 bin-log 记录的数据多怎么办？
为了保证日志一致性需要引入事务控制，即 日志的两阶段提交
可以看到 在最后三步 写入 redo-log 先 prepare，然后写 bin-log，最后提交事务。
当然 MySQL 还有很多其他的日志，这里只讲解了常用的两种，其余日志可以自行查阅学习
