Mysql-(一)-执行流程、Binlog、redo、undo 名词解释

问题 ：一条简单的Select 是如何执行的？

---

在InnoDB中独有的Buffer Pool以及相应的redo:

是不是我们需要的数据多大，我们就一次从磁盘加载多少数据到内存呢?

磁盘 I/O 的读写相对于内存的操作来说是很慢的。如果我们需要的数据分散在磁盘的不同的地方，那就意味着会产生很多次的 I/O 操作。

所以，无论是操作系统也好，还是存储引擎也好，都有一个预读取的概念。也就是说，当磁盘上的一块数据被读取的时候，很有可能它附近的位置也会马上被读取到，这个就叫做局部性原理。那么这样，我们干脆每次多读取一点，而不是用多少读多少。

InnoDB 设定了一个存储引擎从磁盘读取数据到内存的最小的单位，叫做页。操作系统也有页的概念。操作系统的页大小一般是 4K，而在 InnoDB 里面，这个最小的单位默 认是 16KB 大小，它是一个逻辑单位。如果要修改这个值的大小，必须修改源码重新编译安装。

我们要操作的数据就在这样的页里面，数据所在的页叫数据页。

设想一下:
如果对于数据页的操作，每次都直接操作磁盘，从磁盘加载到内存，这样会不会很慢?能不能把这些页缓存呢?

InnoDB 使用了一种缓冲池的技术，也就是把磁盘读到的页放到一块内存区域里面。这个内存区域就叫 Buffer Pool。下一次读取相同的页，先判断是不是在缓冲池里面，如果是，就直接读取，不用再次访问磁盘。

修改数据的时候，先修改缓冲池里面的页。
内存的数据页和磁盘数据不一致的时候，我们把它叫做脏页。
InnoDB 里面有专门的后台线程把 Buffer Pool 的数据写入到磁盘，每隔一段时间就一次性地把多个修改写入磁盘，这个动作就叫做刷脏。

思考一个问题：如果 Buffer Pool 里面的脏页还没有刷入磁盘时，数据库宕机或者重启，这些数据丢失。

如果写操作写到一半，甚至可能会破坏数据文件导致数据库不可用。

为了避免这个问题，InnoDB 把所有对页面的修改操作专门写入一个日志文件，并且
在数据库启动时从这个文件进行恢复操作（实现 crash-safe）。

——用它来实现事务的持久性。这个日志文件就是磁盘的 redo log(叫做重做日志)

问题：
同样是写磁盘，为什么不直接写到 db file 里面去？为什么先写日志再写磁盘？

因为 随机 I/O 和顺序 I/O 的概念。

redo log 有什么特点?

• 1、redo log 是 InnoDB 存储引擎实现的，并不是所有存储引擎都有。支持崩溃恢复是 InnoDB 的一个特性。
• 2、redo log 是物理日志，记录的是“在某个数据页上做了什么修改”。
• 3、redo log 的大小是固定的，前面的内容会被覆盖，一旦写满，就会触发 buffer pool 到磁盘的同步，以便腾出空间记录后面的修改。

redo log 的内容主要是用于崩溃恢复。磁盘的数据文件，数据来自 buffer pool(只 有 redo log 写满了，不能再记录更多内存的数据了，才把 buffer pool 刷盘，然后覆盖 redo log)。

undo log 有什么特点?

除了 redo log 之外，还有一个跟修改有关的日志，叫做 undo log。redo log 和 undo log 与事务密切相关，统称为事务日志,在执行 undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，属于逻辑格式的日志。

---

Binlog

binlog 以事件的形式记录了所有的 DDL 和 DML 语句（因为它记录的是操作而不是数据值，属于逻辑日志），可以用来做主从复制和数据恢复。

跟 redo log 不一样，它的文件内容是可以追加的，没有固定大小限制。

在开启了 binlog 功能的情况下，我们可以把 binlog 导出成 SQL 语句，把所有的操作重放一遍，来实现数据的恢复。

binlog 的另一个功能就是用来实现主从复制，它的原理就是从服务器读取主服务器的 binlog，然后执行一遍。

参考：https://www.cnblogs.com/flgb/p/12122293.html