MySQL是一种分层体系结构的关系数据库。
一共有三层：客户（连接）层，Server层，存储引擎层。
简单理解就是这三层架构。官网的解释在这里。（这个部分建议看8.0的文档，8.0文档补充了架构图，5.7没有放图）
如上图所示（请记住各层的上下顺序，比如索引下推概念中的下推pushdown指的就是server层处理的where下推到存储引擎层）：
客户（连接）层：负责连接处理，验证，安全
Server层：核心层，负责 连接线程处理，NoSQL接口，SQL接口，解析器，优化器，缓存
存储引擎层：各种可插拔替换的存储引擎，如InnoDB，MyISAM，Memory等
主要需要关注Server层和存储引擎层的分工不同：
Server层负责--所有跨存储引擎层的通用功能，如各种接口，存储过程，视图，触发器，SQL语句操作等等
存储引擎层负责--为数据库执行实际的IO操作
**Server层的binlog
开启binlog
同时要设置日志记录格式，参考
查看binlog是否启用：
show variables like 'log_%';
SHOW BINARY LOGS; 列出二进制文件。参考
使用mysqlbinlog查看binlog文件：
mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/mysql-bin.000001
可以看到binlog中记录了每一个操作的sql语句。
**Server层的查询缓存
查询缓存在8.0被取消，因为在一个频繁更新的表中，查询缓存命中率极低。另外它的扩展性问题也是瓶颈所在。
存储引擎层：
在InnoDB磁盘结构一篇中有大致描述Disk Stuctures。关于Memory Structures中则主要是Buffer Pool以及自适应哈希索引。
存储引擎-InnoDB架构，图片来源
Buffer Pool：内存结构中的操作缓冲池，数据在刷盘前的缓冲阵地，提高读写性能。注意，它是直接操作磁盘页结构前的一个内存缓冲，
里面一样是管理的页结构。由于不是实时刷盘，数据在内存中有丢失的风险，因此才引入了redo log机制。
Buffer Pool也是mysql调优的一个重要部分。
由于Buffer Pool的内存大小是有限的，不可能缓存所有的数据页。应该缓存一些频繁操作的“热数据”，同时清理冷却数据，这就涉及到空间管理。
如何判断及取出磁盘页中的热数据呢？
使用了改进的LRU（Least Recently Used）算法 ，将LRU链表的数据做冷热区域划分。具体参考。
**redo log
上文已经介绍了redo log被引出的背景：我们日常操作sql直接操作的其实是innodb的buffer pool，为了保证buffer pool的数据不丢失， 引入了redo log。
redo log恢复内存中未完成的事务/提交，binlog恢复数据库完整记录。仅凭binlog，可能存在丢失未刷盘事务数据的情况，所以mysql不建议删除redo log并直接使用binlog来
恢复数据库。同时恢复数据库时，redo log的操作部分是完全自动的不需要人为介入。
**undo log
undo log是事务开始前将数据状态进行记录，方便进行数据回滚。用来保证事务的原子性(事务过程全部成功/全部失败，借助undo log可以恢复数据到原始状态)。
扩展问题
**为什么存储引擎基于表而不是基于数据库
在InnoDB磁盘结构这一章中，我们知道一个数据库由许多表组成，表即是InnoDB的tablespace。
表空间与数据库到底是什么关系？？有人说存储引擎是基于表的，我们也知道InnoDB里一大堆的tablespace。
但是数据库呢？数据库和它对应在InnoDB物理文件中又是什么？
从mysql服务器物理文件上看，数据库就是对应了一个文件夹，表对应了具体的文件（innodb==》.frm，.ibd）。
创建数据库官方解释：MySQL 中的数据库被实现为包含与数据库中的表相对应的文件的目录。因为最初创建数据库时没有表，所以该Create database语句只在MySQL数据目录下创建一个目录。
标签：binlog,存储,架构,log,数据库,引擎,MySQL,redo From： https://www.cnblogs.com/hangwei/p/17001295.html