MySQL之深入InnoDB存储引擎——Undo页

redo日志解决了事务的持久性问题，而原子性问题则是交给undo日志来保证。有时候事务执行过程中可能遇到服务器的宕机等原因导致事务中断，或者程序在事务执行过程中想取消本次事务，那么为了保证原子性（即要么事务的操作全部完成，要么什么也不做），我们需要把数据恢复为原本的样子，这个过程就成为回滚，为了回滚

MySQL之深入InnoDB存储引擎——redo日志

一、为什么需要redo日志我们知道数据的修改首先是在Buffer Pool中进行的，之后再定时刷到磁盘中。那么如果在事务提交后还没刷新到磁盘中，系统就崩溃了，那么此时数据就丢失了，这就不满足事务的持久性了。而如果我们考虑每次提交之后，都同步将事务中所有的页面刷新到磁盘，这样确实可以保证持久性，但是这

MySQL之深入InnoDB存储引擎——Buffer Pool

InnoDB存储引擎是基于磁盘存储的，并将其中的记录按照页的方式进行管理。在数据库系统中，由于CPU速度与磁盘速度之间的鸿沟，基于磁盘的数据库系统通常使用缓冲池技术来提高数据库的整体性能。在数据库中进行读取页的操作，首先将从磁盘读到的页存放在缓冲池中，这个过程称为将页“FIX”在缓冲池中，在下一次读

MySQL查询执行计划详解（EXPLAIN）

一、单表查询访问方法/访问类型：const：通过主键值或唯一二级索引与一个常熟进行等值查询（不包括NULL），只会生成一条记录ref：普通二级索引与一个常数进行等值比较，可能生成多条记录ref_or_null：ref的前提下可以加上or key is nullrange：对应的扫描区间为若干个单点扫

MySQL表空间结构与页、区、段的定义

一、概念引入1、页InnoDB是以页为单位管理存储空间的，在InnoDB中针对不同的目的设计了各种不同类型的页面。如下（省略了FIL_PAGE或FiL_PAGE_TYPE的前缀）：ALLOCATED：最新分配，还未使用UNDO_LOG：undo日志页INODE：用于存储段的信息IBUF_FREE_L

MySQL处理客户端请求

简单来说 MySQL 主要分为 Server 层和存储引擎层：Server 层：主要包括连接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图，函数等，还有一个通用的日志模块 binlog 日志模块。存储引擎：主要负责数据的存储和读取，采用可以替换

MySQL之深入InnoDB存储引擎——物理文件

一、参数文件当 MySQL 实例启动时，数据库会先去读一个配置参数文件，用来寻找数据库的各种文件所在位置以及指定某些初始化参数。在默认情况下，MySQL 实例会按照一定的顺序在指定的位置读取，没有参数文件也可以运行，这时所有的参数值取决于编译 MySQL 时指定的默认值和源代码中指定参数的默认值。但

MySQL之深入InnoDB存储引擎——Checkpoint机制

一、引入由于页的操作首先都是在缓冲池中完成的，那么如果一条DML语句改变了页中的记录，那么此时页就是脏的，即缓冲池中页的版本要比磁盘的新。那么数据库需要将新版本的页刷新到磁盘。倘若每次一个页发生变化就刷新，那么开销会很大，若热点数据集中在某几个页中，那么数据库的性能将变得非常差。同时如果在缓冲池将新