MySQL原理及优化（一）MySQL架构与执行流程

MySQL架构与执行流程

MySQL体系结构总结

MySQL的内部模块：

1. Connector：用来支持各种语言与SQL的交互。
2. Management Services & Utilities：系统管理和控制工具，包括备份恢复、MySQL复制、集群等。
3. Connection Pool：连接池，管理需要缓冲的资源，包括用户密码权限线程等。
4. SQL Interface：用来接受用户的SQL命令，返回用户需要的查询结果。
5. Parser：用来解析SQL语句。
6. Optimizer：查询优化器。
7. Cache and Buffer：查询缓存，除了行记录的缓存之外，还有表缓存，key缓存，权限缓存等。
8. Pluggable Storage Engines：插件式存储引擎，它提供API给服务层使用，更具体的文件打交道。

架构分层

把MySQL分为三层：

• 连接层：跟客户端对接。
• 服务层：执行操作。
• 存储引擎层：与硬件打交道

一条查询SQL语句是如何执行的

1. 连接

通信协议：MySQL是支持多种通信协议的，可以使用同步/异步的方式，支持长连接/短连接。

2. 缓存

查询缓存：MySQL缓存默认关闭。一般是由ORM框架或者独立的缓存服务器。

3. 解析器

• 词法解析：词法解析就是将一个完整的SQL语句打碎成一个个的单词。
• 语法解析：语法解析对SQL做一些语法检查，然后根据MySQL定义的语法规则，根据SQL语句生成一个数据结构-解析数。任何数据库的中间件，比如Mycat都必须要有词法和语法分析功能。

4. 预处理器

预处理器：检查生成的解析树，解决解析器无法解析的语义。比如，他会检查表和列名是否存在，检查名字和别名，保证没有歧义。

5. 查询优化器、查询执行计划

查询优化器：根据解析树生成的执行计划，然后选择一种最优的执行计划，MySQL里面使用的基于开销（cost）的优化器，哪种执行计划开销最小，就用哪种。

• 查询执行计划：优化器最终把解析树变成一个查询执行计划，它是一个数据结构。

6. 存储引擎

MySQL在存储数据的同时还要组织数据的存储结构，这个存储结构就是由我们的存储引擎决定的。所以存储引擎也叫表结构。
在MySQL里面，支持多种存储引擎，他们是可以替换的，所以叫做插件式的存储引擎。

常见存储引擎：MyISAM、InnoDB

MyISAM

应用范围比较小。表级锁定限定了读/写的性能，因此在Web和数据仓库配置中，它通常用于只读或以读为主的工作。

特点：

• 支持表级锁（插入和更新锁表）。不支持事务。
• 拥有较高的插入（insert）和查询（select）速度。
• 存储了表的行数（count速度更快）。
• 适合只读之类的数据分析的项目。（系统操作日志）

InnoDB

InnoDB是一个事务安全的MySQL存储引擎，它具有提交、回滚和崩溃恢复功能来保护用户数据。行级锁提高了用户并发性和性能。InnoDB将用户数据存储在聚集索引中，以减少基于主键的常见查询的I/O。为了保证数据完整性，InnoDB还支持外键应用完整性约束。

特点：

• 支持事务、外键，因此数据的完整性、一致性更高。
• 支持行级别锁和表级别锁。
• 支持读写并发、写不阻塞读（MVCC）。
• 特殊的索引存放方式，可以减少I/O，提升查询效率。
• 适合：经常更行的表，存在并发读写或者事务处理的业务系统。

7. 执行引擎，返回结果

存储引擎存储了数据的形式，执行引擎利用存储引擎提供的响应的API完成操作。

一条更新SQL语句是如何执行的

更新流程与查询流程基本一致，也要经过解析器、优化器的处理，最后交给执行器。区别就在于拿到符合条件的数据之后的操作。

1. 缓冲池

首先，InnoDB的数据都是放在磁盘上的，InnoDB操作数据有一个最小的逻辑单位，叫做页（索引页和数据页）。我们对于数据的操作，不是每次都直接操作磁盘，因为磁盘的速度太慢。
InnoDB使用了一种缓冲池的技术，也就是把磁盘读到的页放到一块内存区域里面。这个内存区域就叫做Buffer Pool。
下一次读取相同的页，先判断是不是在缓存池里面，如果是，就直接读取，不用再次访问磁盘。
修改数据的时候，先修改缓冲池里面的页。内存数据页和磁盘中的数据不一致的时候，我们把它叫做脏页。InnoDB里面有专门的后台线程把Buffer Pool 的数据写入到磁盘，每隔一段时间就一次性地把多个修改写入磁盘，这个动作就叫做刷脏

2. InnoDB内存结构与磁盘结构

Buffer Pool是InnoDB里面非常重要的一个结构，它的内部有划分几块区域

内存结构

Buffer Pool

Buffer Pool缓存的是页面信息，包括数据页、索引页。默认大小是128M，可以调整。
内存的缓冲池写满了怎么办？（Redis设置的内存满了怎么办？）InnoDB用LRU算法来管理缓冲池（链表实现，不是传统的LRU，分成了yong和old），经过淘汰的数据就是热点数据。

内存缓冲区对于提升读写性能有很大的作用。当需要更新一个数据页时，如果数据页在Buffer Pool中存在，那么就直接更新好了。否则的话就需要从磁盘加载到内存，再对内存的数据页进行操作。也就是说，如果没有命中缓存池，至少要产生一次IO，有没有优化的方式？

Change Buffer 写缓存

如果这个数据页不是唯一索引，不存在数据重复的情况，也就不需要从磁盘加载索引页判断数据是不是重复（唯一性检查）。这种情况下可以先把修改记录在内存的缓冲池里，从而提升更新语句（Insert、Delete、Update）的执行速度。
这一块区域就是Change Buffer。
最后把Change Buffer记录到数据页的操作叫做merge。什么时候发生merge？有几种情况：在访问这个数据页的时候，或者通过后台线程、或者数据库shut down、redo log写满时触发。
如果数据库的大部分索引都是非唯一索引，并且业务是写多读少，不会在写数据后立刻读取，就可以使用Change Buffer（写缓存）。

Adaptive Hash Index

（redo）Log Buffer

如果Buffer Pool里面的脏页还没有刷入磁盘时，数据库宕机或者重启，这些数据丢失。如果写操作写到一半，甚至可能会破坏数据文件导致数据库不可用。
为了避免这个问题，InnoDB把所有对页面的修改操作专门写入一个日志文件，并且在数据库启动时从这个文件进行恢复操作（实现crash-safe）用它来实现事务的持久性。
这个文件就是磁盘的redo log（叫做重做日志），对应于/var/lib/mysql/目录下的ib_logfile0和ib_logfile1，每个48M。
这种日志和磁盘配合的整个过程，其实就是MySQL里面的WAL技术（Write-Ahead Logging），它的关键点就是先写日志，再写磁盘。

问题：同样是写磁盘，为什么不直接写到db file里面去?为什么先写日志，再写磁盘？
随机I/O和顺序I/O：
磁盘的最小组成单元是扇区，通常是512个字节。
操作系统和内存打交道，最小的单位是页Page。
操作系统和磁盘打交道，读写磁盘，最小的单位是块Block。

如果我们所需要的数据是随机分散在不同页的不同扇区中，那么找到响应的数据需要等到磁臂旋转到指定的页，然后盘片寻找到对应的扇区，才能找到我们所需要的一块数据，一次进行此过程知道找完所有的数据，这个就是随机IO，读取数据速度较慢。
假设我们找打了第一块数据，并且其他所需要的数据就在这一块数据后面，那么就不要重新寻址，可以依次拿到我们所需要的数据，这个就叫顺序IO。
刷盘是随机IO，而记录日志是顺序IO。顺序IO效率更高，因此先把修改写入日志，可以延迟刷盘时机，进而提升系统吞吐。
当然redo log也不是每一次直接写入磁盘，在Buffer Pool里面有一块内存区域（Log Buffer）专门用来保存即将日志文件的数据，默认16M，它一样可以节省磁盘IO。

需要注意：redo log的内容主要是用于崩溃恢复。磁盘的数据文件，来自Buffer pool。redo log写入磁盘，不是写入数据文件。

那么Log Buffer什么时候写入log file？
在我们写入数据到磁盘的时候，操作系统本身是有缓存的。flush就是把操作系统缓存区写入到磁盘。log Buffer写入磁盘的时机，由一个参数控制，默认是1。

SHOW V ARIABLES LIKE 'innodb_flush_log_at_trx_commit'；

特点：

• redo log是InnoDB存储引擎实现的，并不是所有的存储引擎都有。
• 不是记录数据页更新之后的状态，而是记录这个页做什么改动，属于物理日志。
• redo log的大小是固定的，前面的内容会被覆盖。

check point是当前要覆盖的位置，如果Writer Pos跟check point重叠，说明redo log已经写满，这时候需要同步redo log 到磁盘中。

磁盘结构

表空间可以看做是InnoDB存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。InnoDB的表空间分为5大类。

1. 系统表空间（system tablespace）

在默认的情况下，InnoDB存储引擎中有一个共享表空间（/var/lib/mysql/ibdata1），也叫系统表空间。
InnoDB系统表空间包含InnoDB数据字典和双写缓冲区，Change Buffer 和Undo Logs，如果
没有指定file-per-table，也包含用户创建的表和索引数据。

• 数据字典：由内部系统表组成的，存储表和索引的元数据（定义信息）。
• 双写缓存（InnoDB的一大特性）：

InnoDB的页和操作系统的页大小不一致，InnoDB页大小一般为16K，操作系统页大小我4K，InnoDB的页写入磁盘时，一个页需要分4次写。

如果存储引擎正在写如页的数据到磁盘时发生了宕机，可能出现页只写了一部分的情况，比如只写了4K，就宕机了，这种情况叫做部分写失效（partial page write），可能会导致数据丢失。

所以在redo log之前，需要一个页的副本。如果出现了写入失效，就用页的副本来还原这个页，然后再应用redo log。这个页的副本就是double write，InnoDB的双写技术。通过它实现了数据页的可靠性。

跟redo log一些样，double write由两个部分组成，一部分是内存double write，一部分是磁盘上的double write。因为double write是顺序写入的，不会带来很大的开销。

在默认的情况下，所有的表共享一个系统表空间，这个文件会越来越大，而且它的空间不会收缩。

独占表空间 (file-per-table tablespaces)

我们可以让每一张表独占一个表空间。这个开关通过innodb_file_per_table设置，默认开启。
开启后，则每张表会开辟一个表空间，这个文件就是数据目录下的ibd文件（例如：/var/lib/mysql/gupao/user_innodb.ibd），存放表的索引和数据。
但是其他类型的数据，如回滚（undo）信息，插入缓存索引页、系统事务信息，二次写缓存（Double write buffer）等还是存放在原来的共享表空间内。

通用表空间（general tablespaces）

通用表空间也是一种共享的表空间，更ibdata1类似。
可以创建一个通用的表空间，用来存储不同数据库的表，数据路径和文件可以自定义。语法：

create tablespace ts2673 add datafile '/var/lib/mysql/ts2673.ibd' file_block_size=16K engine=innodb;

在创建表的时候可以指定表空间，用ALTER修改表空间可以转移表空间。

create table t2673(id integer) tablespace ts267

不同表空间的数据是可以移动的。删除表空间需要先删除里面所有的表。

临时表空间 （temporary tablespaces）

存储临时表的数据，包括用户创建的临时表，和磁盘的内部临时表。对应数据目录下的ibtmp1文件。当数据服务器正常关闭的时候，该表空间被删除，下次重新产生。

redo log

undo log tablespaces

undo log（撤销日志或回滚日志）记录了事务发生之前的数据状态（不包括select）。如果修改数据时出现了异常，可以用undo log来实现回滚操作（保持原子性）。
在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的。属于逻辑格式的日志。

redo log和undo log与事务密切相关，统称为事务日志。
undo log的数据默认在系统表空间ibdata1文件中，因为共享表空间不会自动收缩，也可以单独创建一个undo表空间。

有了这些日志后，我们总结一下更新流程。（name原值是wang）

update user set name = 'wg' where id = 1;

1. 事务开始，从内存或磁盘取到这条数据，返回个Server的执行器；
2. 执行器修改这一行的数据的值为wg；
3. 记录name = wang到undo log；
4. 记录name = wg到redo log；
5. 调用存储引擎的接口，在内存（Buffer Pool）中修改name = wg；
6. 事务提交。

3. Binlog

binglog以事件的形式记录了所用的DDL和DML语句（因为它记录的是操作而不是数据值，属于逻辑日志），可以用来做主从复制和数据恢复。
跟redo log不一样，它的文件内容是可以追加的，没有固定大小限制。
在开启了binglog功能的情况下，我们可以把binglog导出成sql语句，把所有的操作重放一遍，来实现数据的恢复。
binglog的另一个功能是用来实现主从复制，它的原理就是从服务器读取主服务器的binglog，然后执行一遍。

有了这两个日志后，我们看一下更新语句的执行：

update teacher set name='盆鱼宴' where id=1;

1. 先查询到这条数据，如果有缓存，会使用缓存；
2. 把name改成盆鱼宴，然后调用引擎的API接口，写入这一行数据到内存，同事记录redo log。这时redo log进入prepare状态，然后告诉执行器执行完了，可以随时提交。
3. 执行器收到通知后记录binlog，然后调用存储引擎的接口，设置redo log为commit状态。
4. 更新完成。