【数据库】MySQL架构介绍——InnoDB引擎架构
什么是关系型数据库？什么是非关系型数据库？
**关系型数据库：指采用了关系模型来组织数据的数据库。**关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。
关系型数据库存在的问题
-
网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘
I/O是一个很大的瓶颈 -
网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的
-
在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像
web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。当需要对数据库系统进行升级和扩展时，往往需要停机维护和数据迁移。 -
性能欠佳：在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一个格式化的数据结构。
数据库事务必须具备ACID特性，ACID分别是Atomic原子性，Consistency一致性，
Isolation隔离性，Durability持久性。
**非关系型数据库：指非关系型的，分布式的，且一般不保证遵循ACID原则的数据存储系统。**非关系型数据库以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，不局限于固定的结构，可以减少一些时间和空间的开销。
不足：
只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，关系型数据库显的更为合适。不适合持久存储海量数据
【 比较：】
-
成本：
Nosql数据库简单易部署，基本都是开源软件，不需要像使用Oracle那样花费大量成本购买使用，相比关系型数据库价格便宜。 -
查询速度：
Nosql数据库将数据存储于缓存之中，而且不需要经过SQL层的解析，关系型数据库将数据存储在硬盘中，自然查询速度远不及Nosql数据库。 -
存储数据的格式：
Nosql的存储格式是key,value形式、文档形式、图片形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型。 -
扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难。
Nosql基于键值对，数据之间没有耦合性，所以非常容易水平扩展。 -
持久存储：
Nosql不使用于持久存储，海量数据的持久存储，还是需要关系型数据库 -
数据一致性：非关系型数据库一般强调的是数据最终一致性，不像关系型数据库一样强调数据的强一致性，从非关系型数据库中读到的有可能还是处于一个中间态的数据，
Nosql不提供对事务的处理。
MySQL架构介绍
InnoDB引擎架构
（1）InnoDB表的类型
在InnoDB存储引擎表中，每张表都有个主键，如果在创建表时没有显式地定义主键（Primary Key），则InnoDB存储引擎会按如下方式选择或创建主键。
- 首先表中是否有非空的唯一索引（Unique NOT NULL），如果有，则该列即为主键。
- 不符合上述条件，InnoDB存储引擎自动创建一个6个字节大小的指针。
（2）InnoDB逻辑存储结构
单位：表>段>区>页>行
所有数据被逻辑地存放在一个空间中，我们称为表空间（tablespace）。
表空间又由段（segment）、区（extent）、页（page）组成。1 extent = 64 pages。
-
表空间
表空间可以看做是InnoDB存储引擎逻辑结构的最高层，所有的数据都是存放在表空间中。
-
段
显示了表空间是由各个段组成的，常见的段有数据段、索引段、回滚段等。InnoDB存储引擎表是索引组织的（index organized），因此数据即索引，索引即数据。
-
区
区是由64个连续的页组成的，每个页大小为16KB，即每个区的大小为1MB。对于大的数据段，InnoDB存储引擎最多每次可以申请4个区，以此来保证数据的顺序性能。
在我们启用了参数innodb_file_per_talbe后，创建的表默认大小是96KB。区是64个连续的页，那创建的表的大小至少是1MB才对啊？其实这是因为在每个段开始时，先有32个页大小的碎片页（fragment page）来存放数据，当这些页使用完之后才是64个连续页的申请。
-
页
同大多数数据库一样，InnoDB有页（page）的概念（也可以称为块），页是InnoDB磁盘管理的最小单位。
-
行
InnoDB存储引擎是面向行的（row-oriented），也就是说数据的存放按行进行存放。每个页存放的行记录也是有硬性定义的，最多允许存放16KB/2～200行的记录，即7992行记录。
（3）InnoDB物理存储结构
从物理意义上来看，InnoDB表由共享表空间、日志文件组（更准确地说，应该是Redo文件组）、表结构定义文件组成。若将innodb_file_per_table设置为on，则每个表将独立地产生一个表空间文件，以ibd结尾，数据、索引、表的内部数据字典信息都将保存在这个单独的表空间文件中。表结构定义文件以frm结尾，这个是与存储引擎无关的，任何存储引擎的表结构定义文件都一样，为.frm文件。
参考：InnoDB的表类型,逻辑存储结构,物理存储结构
InnoDB 存储引擎
在说明InnoDB引擎如果实现ACID之前，首先对InnoDB引擎架构中基本知识进行介绍：
缓存池（Buffer Pool）
缓冲池的设计目的为了协调CPU速度与磁盘速度的鸿沟。
Buffer Pool中包含了磁盘中部分数据页的映射。
当从数据库读取数据时，会先从Buffer Pool中读取数据，如果Buffer Pool中没有，则从磁盘读取后放入到Buffer Pool中。
当向数据库写入数据时，会先写入到Buffer Pool中，Buffer Pool中更新的数据会定期刷新到磁盘中（此过程称为刷脏）。
缓冲池：InnoDB存储引擎是基于磁盘存储的，并将其中的记录按照页的方式进行管理。缓冲池简单来说就是一块内存区域，通过内存的速度来弥补磁盘速度较慢对数据库性能的影响。
刷脏：对于数据库中页的修改操作，则首先修改在缓冲池中的页，然后再以一定的频率刷新到磁盘上。这里需要注意的是，页从缓冲池刷新回磁盘的操作并不是在每次页发生更新时触发，而是通过一种称为Checkpoint的机制刷新回磁盘。同样，这也是为了提高数据库的整体性能。
在LRU列表中的页被修改后，称该页为脏页( dirty page)，即缓冲池中的页和磁盘上的页的数据产生了不一致。这时数据库会通过CHECKPOINT机制将脏页刷新回磁盘，而Flush列表中的页即为脏页列表。需要注意的是，脏页既存在于LRU列表中，也存在于Flush列表中。LRU列表用来管理缓冲池中页的可用性，Flush列表用来管理将页刷新回磁盘，二者互不影响。
Checkpoint技术：
前面已经讲到了，缓冲池的设计目的为了协调CPU速度与磁盘速度的鸿沟。因此页的操作首先都是在缓冲池中完成的。如果一条DML语句，如Update或Delete改变了页中的记录，那么此时页是脏的，即缓冲池中的页的版本要比磁盘的新。数据库需要将新版本的页从缓冲池刷新到磁盘。
倘若每次一个页发生变化，就将新页的版本刷新到磁盘，那么这个开销是非常大的。若热点数据集中在某几个页中，那么数据库的性能将变得非常差。同时，如果在从缓冲池将页的新版本刷新到磁盘时发生了宕机，那么数据就不能恢复了。为了避免发生数据丢失的问题，当前事务数据库系统普遍都采用了Write Ahead Log策略，即当事务提交时，先写重做日志，再修改页。当由于发生宕机而导致数据丢失时，通过重做日志来完成数据的恢复。这也是事务ACID中D (Durability持久性）的要求。
Checkpoint(检查点）技术的目的是解决以下几个问题:
- 缩短数据库的恢复时间;
- 缓冲池不够用时，
- 将脏页刷新到磁盘;重做日志不可用时，刷新脏页。
当数据库发生宕机时，数据库不需要重做所有的日志，因为Checkpoint 之前的页都已经刷新回磁盘。故数据库只需对Checkpoint后的重做日志进行恢复。这样就大大缩短了恢复的时间。
日志缓冲区（Log Buffer）
当在MySQL中对InnoDB表进行更改时，这些更改首先存储在InnoDB日志缓冲区的内存中，然后写入通常称为**重做日志（redo logs）**的InnoDB日志文件中。
双写机制缓存（DoubleWrite Buffer）
Doublewrite Buffer是开在共享(系统)表空间的物理文件的 buffer,其大小是2MB.是一个一分为二的2MB空间。
刷脏操作开始之时,先进行脏页**‘备份’**操作.将脏页数据写入 Doublewrite Buffer.
将Doublewrite Buffer(顺序IO)写入磁盘文件中(共享表空间) 进行刷脏操作.(绝大多数是随机IO)
回滚日志（Undo Log）
Undo Log记录的是逻辑日志.记录的是事务过程中每条数据的变化版本和情况.
在Innodb 磁盘架构中Undo Log 默认是开在共享(系统)表空间的物理文件的Buffer.
在事务异常中断,或者主动(Rollback)回滚的过程中,Innodb基于 Undo Log进行数据撤销回滚,保证数据回归至事务开始状态.
重做日志（Redo Log）
Redo Log通常指的是物理日志，记录的是数据页的物理修改.并不记录行记录情况。（也就是只记录要做哪些修改，并不记录修改的完成情况）
当数据库宕机重启的时候，会将重做日志中的内容恢复到数据库中。
InnoDB存储引擎是第一个完整支持ACID事务的MySQL存储引擎。其特点是行锁设计、支持MVCC、支持外键、提供一致性非锁定读，同时被设计用来最有效地利用以及使用内存和CPU。
InnoDB引擎
显示了InnoDB的存储引擎的体系架构，从图可见，InnoDB存储引擎有多个内存块，可以认为这些内存块组成了一个大的内存池，负责如下工作:
-
维护所有进程/线程需要访问的多个内部数据结构。
-
缓存磁盘上的数据，方便快速地读取，同时在对磁盘文件的数据修改之前在这里缓存。
-
重做日志（redo log）缓冲。
后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存的是最近的数据。此外将已修改的数据文件刷新到磁盘文件，同时保证在数据库发生异常的情况下InnoDB能恢复到正常运行状态。