名词说明
MYSQL驱动
在底层跟数据库建立网络连接
系统连接池
建立数据库连接是一个非常耗时的操作，而实际业务中往往会有很多请求去访问数据库，所以要使用一个数据库连接池来维护多个数据库连接。线程使用完连接后不用销毁，直接放回连接池以便后续使用。
MYSQL连接池
维护了与系统之间的多个数据库连接。除此之外，系统每次与MYSQL建立连接的时候，还会进行账户信息验证，库表权限验证。
SQL接口
MYSQL内部提供的一个组件，负责执行线程传递过来的SQL语句
查询解析器
负责对SQL语句进行解析，知道做什么操作，对哪张表操作，操作哪些数据，怎么操作等
查询优化器
得到一个效率最高的执行计划
执行器
根据查询优化器选择的一套执行计划，不停的调用存储引擎的各种接口去完成SQL语句的执行计划。
比如执行器可能先会调用存储引擎的一个接口去获取user表的第一行数据，判断id是否为我们期望的一个值，如果不是就继续调用接口获取下一行数据继续判断
存储引擎接口
执行SQL语句，按照一定的步骤去查询内存缓存数据，更新磁盘数据，查询磁盘数据等。
流程图
InnoDB内存结构
缓冲池
缓冲池（Buffer Pool），方便查询的时候，直接可以从内存缓冲池中获取，减少对磁盘的查询
undo日志
用于回滚数据
更新缓存数据流程
- 记录加载到缓冲池
- 加锁
- 旧值写入undo日志文件
- 更新缓冲池中的记录，此时这个数据就是脏数据了（和磁盘数据不一致）
redo日志
记录内存中的数据修改，避免内存修改后没有同步到磁盘上。InnoDB存储引擎特有的一个东西。在mysql重启时会加载redo日志中的修改到内存里去，然后等适当时机通过IO线程把修改后的数据同步到磁盘上。
RedoLog Buffer
内存中的一个缓冲区。暂时存放redo日志。
binlog
归档日志，偏向物理性质的重做日志，类似于，对XX表中某一行数据进行了修改，修改后的值是XXX；在提交事务的时候，还会把binlog的文件名，位置以及commit标记写入对应的redo日志中。
事务提交流程
1.根据策略(innodb_flush_log_at_trx_commit)，把redo日志从redo log buffer刷到磁盘文件。
0：不管事务，每一秒都会把日志写入，并且刷到磁盘。事务提交时不会主动触发写磁盘的操作。
1：只要事务提交成功，redo log就必然在磁盘里（建议）
2：提交事务的时候，把redo日志写入磁盘对应的os cache缓存，而不是直接进入磁盘文件，可能要过一段时间再写入磁盘
根据策略(sync_binlog)，把binlog日志写入磁盘
0：写入os cache，一段时间后写入磁盘（默认）
1：强制在提交事务的时候，直接写入到磁盘文件- 把写入磁盘的binlog日志的文件名，位置以及一个commit标记写入到redo日志
- 至此，事务才算提交完成。只要redo日志中不存在commit标记则认为提交失败。