MySQL_10.MySQL体系架构

一.MySQL主要物理文件有
(1)Redolog        重做日志文件
(2)Undolog        回滚日志文件
(3)Binlog        二进制日志文件
(4)Relaylog        中继日志文件（主从复制、slave才有）
(5)Errorlog        错误日志文件
(6)Querylog        全查询日志文件
(7)Slowlog        慢查询日志文件
(8)Data            数据文件（表结构文件/表数据文件）

1.参数文件 my.cnf :
mysq实例启动的时候在哪里可以找到数据库文件,并且指定某些初始化参数,这些参数定义了某种内存结构的大小等设置,
Mysq实例启动时,会先读取配置参数文件my.cnf

2.日志文件 :
记录mysq对某种条件做出响应时候写入的文件,记录了影响mysql数据库的各种类型活动,
常见的日志文件有错误日志、二进制日志、慢查询日志、全查询日志、redo日志、undo日志。
(1)错误日志:错误日志对mysql的启动、运行、关闭过程进行了记录问题分析必看。
(2)二进制日志:记录了对数据库进行变更的操作,但是不包括 select操作以及show操作。主要用于恢复(recovery)、复制(replication)。
(3)慢査询日志:记录运行较慢的sql语句信息,给sql语句的优化带来很好的帮助。
(4)全查询日志:记录mysql所有的请求,数据库审计加问题排查跟踪性,损失3%-5%性能。
(5)Redo日志:数据库都是日志先行,先写日志,再写数据文件,保证恢复与完整性，这个对 innodb存储引擎非常重要,因为它们记录了对于innodb存储引擎的事务日志。
(6)Undo日志:里面存储了与redo相反的数据更新操作,如果 rollback的话,就把undo段里面数据回写到数据文件里面。
(7)Redo与undo他们并不是各自独立没有关系的,他们是有关联的,交替合作来保证数据的一致性和安全性。

3.Socket文件 :
当用linux的mysql命令行窗口本地localhost登录的时候需要的文件, 可以用参数 socket控制,一般默认在/tmp目录下

4.Pid 文件 :
mysql实例的进程文件,当mysql实例启动的时候,会将自己的进程id写入文件中,该文件即为pid文件,由参数 pid_file控制,默认路径位于数据库目录下

5.mysql 数据文件 :
存放mysql表结构定义文件,如:*.frm
存放mysql表数据的文件,如:*.ibd 。
注意innodb没有索引文件 *.myi

6.存储引擎文件 :
记录存储引擎信息的文件,innodb存储引擎在存储设计上模仿了oracle,该文件就是默认的表空间文件,可以用多个文件组成一个表空间,例如:ibdata*文件

二.mysql数据库与实例的关系 
Oracle 是多进程,而mysql是单进程多线程 。
mysql实例，后台进程+内存结构,mysql实例在系统上的表现就是一个进程,实例才是真正用于操作数据库文件的。
mysql:1个实例对应1个数据库或者1个实例对应多个数据库。
ORACLE:1个实例对应1个数据库或者多个实例对应1个数据库。
Oracle数据库中，一个会话对应一个连接进程。（进程）
mysql 数据库中,一个会话对应一个连接线程。（线程）
mysql不存在实例名，服务名，只有数据库名，如果在一台服务器上存在多个mysql实例，只有通过端口来区分不同实例之间的存在

三.存储引擎 
概念:mysql存储引擎称为表类型（说白了就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法）
mysql用得比较多存储引擎:Myisam、 Innodb、 memory。
注:5.7以后主要用Innodb

1.MYISAM存储引擎(了解):
这种存储引擎不支持事务,不支持行级锁(支持表锁),只支持并发插入的表锁,主要用于高负载的 select
支持3种不同的存储格式,分别是:静态表、动态表、压缩表静态表。
(1)静态表:
表中的字段都是非变长字段,这样每个记录都是固定长度的,优点存储非常迅速,容易缓存,出现故障容易恢复;
缺点是占用的空间通常比动态表多(因为存储时会按照列的宽度定义补足空格)。
(2)动态表:
记录不是固定长度的,这样存储的优点是占用的空间相对较少。
缺点∶频繁的更新、删除数据容易产生碎片,需要定期得对表进行优化/检査/修复
(3)压缩表:
因为每个记录是被单独压缩的,所以只有非常小的访问开支

2.memory存储引擎:
使用存在于内存中的内容来创建表。
每个 memory表只实际对应一个磁盘文件,格式是 .frm ;
该文件只存储表的结构,而其数据文件,都是存储在内存中,这样有利于对数据的快速处理,提高整个表的处理能力。
memory因为它的数据是放在内存中的,但是一旦服务关闭,表中的数据就会丢失掉

3.INNODB存储引擎(重点):
该存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全,支持行级锁、使用了B+ Tree索引、支持自动增长列,支持外键约束。
但是对比MYISAM引擎,写的处理效率会差一些,并且会占用更多的磁盘空间以保留数据和索引。
memory存储引擎默认使用哈希(HASH)索引,其速度比使用B+ TREE索引要快。
Hash索引结构其检索效率非常高,索引的检索可以一次定位。
B-Tree索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问。
所以Hash索引的查询效率要远高于B-Tree索引。
虽然Hash索引效率高,但是Hash索引本身由于其特殊性也带来了很多限制和弊端,功能有限,支持也有限，一般生产环境都是使用B-TREE索引
注:在有限的范围内表达无限的场景，这就是hash

四.InnoDB逻辑存储结构
1.mysql 逻辑存储结构是 表空间 --> 段 --> 区 --> 页。
表空间     : 所有的数据都放在表空间里面。
段        : 表空间有若干个段组成，常见的有数据段/索引段/回滚段等。
区        : 每64个连续的页组成区，一个区大小为1M。
页        : 页是InnoDB磁盘管理的最小单元，固定大小为16K。

2.表空间
表空间可以看做是InnoDB存储引擎逻辑结构的最高层，所有的数据都是存放在表空间中
默认情况下InnoDB存储引擎有一个共享表空间ibdata1，即所有数据都放在这个表空间内
对于启用了innodb_file_per_table的参数选项，需要注意的是，每张表的表空间内存放的只是数据。
对于索引和插入缓冲，其他类的数据，如撤销（Undo）信息、系统事务信息、二次写缓冲（double write buffer）等还是存放在原来的共享表空间内。
这也就说明了另一个问题：即使在启用了参数innodb_file_per_table之后，共享表空间还是会不断地增加其大小
修改表空间管理方式：
(1)修改innodb_file_per_table这个参数即可
on表示为独立表空间；off表示为共享表空间
(2)修改innodb_file_per_table的参数值即可
innodb_file_per_table=1 为使用独占表空间
innodb_file_per_table=0 为使用共享表空间
注:但是修改无法影响之前已经使用过的共享表空间和独立表空间
show variables like innodb_file_per_table;                  --查看当前表空间管理方式
show global variables like '%innodb_file_per_table%';        --查看独立表空间
show global variables like '%innodb_data_file_path%';        --查看共享表空间
注:物理文件为ibdata文件，默认情况下ibdata存放InnoDB表（InnoDB数据字典）元数据、undo logs、the change buffer, and the doublewrite buffer

3.段(segment)
主要的段有
(1)Leaf node segment ：        叶子节点段，这个段是专门存放B+树叶子节点的段，而我们都知道在B+树中叶子节点保存的都是数据，所以该段也称数据段。
(2)Non-Leaf node segment ： 非叶子节点段，这个段中存放着B+树的非叶子节点，也即索引，所以也称索引段。
(3)Rollback segment ：         回滚段，用来临时的保存当数据库数据发生改变时的先前值

4.区(Extent)
​区是由连续的页组成的空间，一个区中默认存放着64个page，每个page默认是16KB，所以默认情况下，一个区的大小为1MB。
一次性从磁盘申请45个区，也就是说，每一次ibd文件增长，一次增长45MB，避免了区在磁盘中存在碎片化

5.页(page)
​页是InnoDB中磁盘读写的最小逻辑单位，默认是16KB，而一个数据页就是一个B+树的叶子节点(B+ Tree Node)
主要的页有:
(1)数据页（B-tree Node）。
(2)Undo页（Undo Log Page）。
(3)系统页（System Page）。
(4)事务数据页（Transaction system Page）。
(5)插入缓冲位图页（Insert Buffer Bitmap）。
(6)插入缓冲空闲列表页（Insert Buffer Free List）。
(7)未压缩的二进制大对象页（Uncompressed BLOB Page）。
(8)压缩的二进制大对象页（Compressed BLOB Page）。

6.行(Row)
InnoDB表中的数据按行存储，InnoDB存储引擎是面向行的（row-oriented），也就是说数据的存放按行进行存放，
每个页存放的行记录也是有硬性定义的，最多允许存放16KB/2～200行的记录，即7992行记录

五.InnoDB存储引擎体系架构
主要分为4大块，9小块
1.Buffer Pool :Innodb Buffer Pool 可以缓存索引数据,还会缓存表的数据,而且完全按照数据文件中的数据快结构信息来进行缓存,
这一点和 Oracle Sga中的 buffer cache非常类似
(1)Undo page:事务提交/回滚处理，保证事务的一致性和完整性，还有进行旧版本的页删除操作

(2)change buffer/insert buffer page:是mysql5.5加入的新特性，change buffering是insert buffer的加强，insert buffer只针对insert有效，
change buffering对insert、delete、update(delete+insert)、purge都有效
工作原理
当修改一个索引块(secondary index)中的数据时，索引块在buffter pool中不存在，修改信息就会被cache在change buffer中，
当通过索引扫描把需要的索引块读取到buffer pool时，会和change buffer中修改信息合并，再择机写回disk。目的还是为了减少随机IO带来性能损耗

(3)Adaptive Hash Index :InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引
注:自适应哈希索引通过缓冲池的B+树构造而来,因此建立的速度很快。而且不需要将整个表都建哈希索引

(4)Index Page : 对记录的操作缓存,主要有3种操作记录查找、插入、删除,是对数据操作的一个缓存，正真保存数据页的缓存区

(5)Lock Info : 缓存InnoDB 存储的锁信息

(6)Data Dictionary : 缓存一些数据字典信息，例如表结构这些

2.Additional Memory Pool : 附加内存池
用来保存数据字典信息和其他内部数据结构的内存池的大小，初始化为8M，数据库中的表数量越多,该缓冲区会占得空间越大，
如果 Innodb用完了内存池中的内存,就会从操作系统中分配内存

3.Redo Log Buffer : redo entries --> redo log buffer --> 重做日志文件。
innodb_log_buffer_size的大小（默认16M），将重做日志缓冲中的内容刷新到外部磁盘的重做日志文件中的3种情况：
(1)Master thread每秒将重做日志缓冲刷新到重做日志文件;
(2)每个事务提交时会将重做日志缓冲刷新到重做日志文件;
(3)当重做日志缓冲池剩余空间小于1/2时,重做日志缓冲刷新到重做日志文件;
select @@innodb_log_buffer_size / 1024 / 1024 MB;    --查看重做日志缓冲区大小

4.Binlog Buffer : 二进制日志缓冲区
主要用来缓存由于各种数据变更操做所产生的 Binary Log信息，为了提高系统的性能,mysql并不是每次都是将二进制日志直接写入 Log File,
而是先将信息写入 Binlog Buffer中,当满足某些特定的条件之后再一次写入 Log File文件中。
二进制日志和重做日志的对比：

--类别区分：
二进制日志    ：记录mysql数据库相关的日志记录,包括 INNODB、Myisam等其它存储引擎的日志。
重做日志    ：只记录innodb存储引擎本身的事务日志。

--内容区分：
二进制日志    ：记录事务的具体操作内容，是逻辑日志。
重做日志    ：记录每个页的物理更改情况。

--时间区分：
二进制日志    ：只在事务提交完成后进行写入,只写磁盘一次,不论这个事务量有多大。
重做日志    ：在事务进行中,就不断有重做日志条目 (redo entry)写入重做日志文件

5.Double Write : 是InnoDB表空间 ibdata中一块连续的128 page * 16k = 2M的存储空间
InnoDB用户脏刷数据，是先把数据刷到ibdata的Double Write Buffer的区域中，然后Double Write再刷到数据文件中，
它的作用的是处理产生 partial write(部分写入)时候的 data recovery
注意：Double Write不是内存区域，而是物理文件ibdata表空间中的区域，相当于是把磁盘当内存使用
double write的机制：
(1)data page1从idb数据文件中被读取到buffer pool中
(2)user A发起事务T1 开始修改 page1，此时page1 会变成一个脏页(dirty page)
(3)同时mysql会开始写redo log，当然这里是先将page1的变更写入redo buffer，并不会立刻落盘
(4)User A 开始发起commit提交这个事务T1
(5)此时mysql会将redo buffer内容flush到redo log中，即完成此时的redo落盘操作
(6)完成日志落盘后，Page1 会被先通过memcopy到double write buffer中
(7)最后double write buffer被写满或者用户本身发起了刷脏行为，那么会把数据从double write buffer写入到数据文件中

写入到double write buffer成功，但是page1 在写入到数据文件中时失败，进行恢复问题
解决:
由于double write buffer中是写成功了，数据文件写失败，那么在恢复时mysql在检查这个page1时发现checksum有问题，
会直接从double write buffer中copy 已经写完成的page1覆盖到数据文件对应位置，然后再去应用redo等等
注:不完整的页是不能通过redo恢复的,double write机制更像在数据落盘之前多了一层缓冲