MySQL执行流程
select语句执行流程
增删改语句执行流程
update语句的整体执行流程和select语句是一样的。只是少了缓存的那一步骤。
mysql想完成数据的修改，会先从存储引擎层读取数据，把数据读取到服务层进行数据的修改，再通过存储引擎层把数据更新到数据库中。
mysql每次读取数据都会读取16384B的数据，默认是16KB的数据。一页的数据。
在innodb引擎中设计了 buffer pool 缓冲区。Mysql从磁盘中通过IO读取数据到buffer pool中，引擎从bffer pool中获取数据，然后修改，再把数据写入到buffer pool中。从而完成读写的操作，因为是基于内存的操作，所以速度是非常快的。
脏数据：buffer pool中的数据，还没有同步到磁盘中的数据称为脏数据。
innodb的脏页刷新机制说明：
1、当innodb中的脏页比例超过innodb_max_dirty_pages_pct_lwm的值时，这个时候innodb就会开始刷新脏页到磁盘。
2、当innodb中的脏页比例超过innodb_max_dirty_pages_pct_lwm的值，而且还超过innodb_max_dirty_pages_pct时innodb就会进入勤快刷新模式(agressively flush）这个模式下innodb会把脏页更快的刷新到磁盘。
3、还有一种情况叫做sharp checkpoint ,当innodb要重用它之前的redo文件时，就会把innodb_buffer_pool中所有与这个文件有关的页面都要刷新到磁盘；这样做就有可能引起磁盘的IO风暴了，轻者影响性能，重者影响可用性。
对于控制刷新机制的各个参数的说明：
1、innodb_max_dirty_pages_pct默认值为75，也就是说当脏页比例超过75%时才会进入勤快刷新模式。
2、innodb_max_dirty_pages_pct_lwm默认值是0，0对于innodb_max_dirty_pages_pct_lwm来说是一个特殊值，它表示不启用这个功能；由于没有启用这个功能，也就是说innodb_buffer_pool中的脏页比例会操持在75%左右。
Mysql会在后台使用若干线程，负责把buffer pool中的数据刷新到磁盘中去。
后台常用的线程：
master thread 主线程
IO thread IO操作的线程
Purge thread 清理数据和日志的线程
Page C1eaner thred 刷脏的线程
查看buffer pool的大小，默认是128M
# 查询innodb buffer pool相关配置
show VARIABLES like '%innodb_buffer_pool%';
数据存储到buffer pool中，默认是128M，如果buffer pool存满了，那么innodb引擎会使用改良的LRU算法清理数据。
注意：LRU算法是最近最久未使用法，mysql会对LRU的算法进行改良。
官网文档地址：https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html
冷热分离的方式:
新的数据刚进来的时候进入冷区域，如果下一秒被调用就进去热区域顶部，热区域的数据都会向下移动。
redo log 日志
redo log日志是innodb存储引擎自带的。
避免服务器宕机或者其他突发事件，导致需要保存到数据库的数据还没来得及存储，所以才有了redo log。在mysql事务的层面上来说，redo log保证了数据的持久性。
问题：数据没有直接存入到磁盘上，而是先存入到buffer pool中，然后再刷入磁盘，目的是为了性能考虑，但是现在有需要存入到redo log 日志的磁盘文件中，这样性能不就下降了？
答案：性能肯定是会有一些影响，但是需要保证数据可恢复的能力。写入redo log磁盘文件中的速度会更快一些。
随机磁盘IO和顺序磁盘IO的区别。
随机磁盘IO的情况是数据是会分散到不同的扇区去存储，因为底层是通过索引的顺序来存储，索引会存储到不同的扇区。那么更新数据的时候会增加寻道的时间，写入数据会变慢。
顺序磁盘IO是按着顺序追加写入的。 速度会快一些。
# 通过命令查看innodb_log相关的信息。
show VARIABLES like '%innodb_log%';
默认是分成2组innodb_log_files_in_group，所以产生2个日志文件。
每个文件的大小默认是48Minnodb_log_file_size 固定的（可以修改），数据满了会产生覆盖的效果。
站在mysql事务的角度，redo log日志是事务持久性的保证。
log buffer 刷盘机制(什么时候将记录的数据存储到磁盘中)，官网说明
log buffer刷盘时间间隔
每隔一秒刷盘一次，但是具体的刷盘策略由innodb_flush_log_at_trx_commit参数来决定。
log buffer 刷盘机制:
innodb_flush_log_at_trx_commit：用来控制redo log刷新到磁盘的策略。
当设置为1的时候，事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。这种方式即使系统崩溃也不会丢失任何数据，但是因为每次提交都写入磁盘，IO的性能较差。
当设置为0的时候，事务提交时不会将log buffer中日志写入到os buffer，而是每秒写入os buffer并调用fsync()写入到log file on disk中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的，当系统崩溃，会丢失1秒钟的数据。
当设置为2的时候，每次提交都仅写入到os buffer，然后是每秒调用fsync()将os buffer中的日志写入到log file on disk。
undo log日志
undo log日志是innodb存储引擎自带的。
undo log可以称为撤销日志或者回滚日志，站在事务的角度，undo log可以保证事务的原子性。
日志中记录的反向操作，例如：把username=”张三” 修改成了username=”赵四”，那么undo log中记录的是原来的值，即 username=”张三” 这样数据库再发生回滚操作的时候，可以把数据恢复回来。
本地存储位置：
show VARIABLES like '%undo%';
bin log 日志
bin log是mysql服务端的日志。
binary log 二进制日志，属于mysql服务层的日志。bin log是默认关闭的。
binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。
binlog不会记录SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改，但你可以通过查询通用日志来查看MySQL执行过的所有语句。
主要作用是主从复制和数据恢复的作用。
特点：
记录DDL和DML的语句，属于逻辑日志
没有固定大小限制，内容可以追加
Server层实现，可以被所有存储引擎使用
用于数据恢复和主从复制。
show GLOBAL VARIABLES like '%log_bin%';
bin log主从复制的原理流程图:
总结
