MySQL运行机制
开局一张图 内容全靠编
本文主要说一下，应用程序在与数据库交互时，数据库的大概执行流程。整体上了解一下一条SQL的流转。
- 建立连接
应用程序与MySQL各自使用线程池，来维护之间的连接。每个连接都是一个线程，从而实现并发访问MySQL。
- 客户端发送 SQL
- 查询缓存，查询语句与缓存中的完全一致（包括参数且不能存在不确定参数比如 now()），则将查询到的结果返回。
- SQL 解析器，解析 SQL 判断 SQL 是否合法。
- 查询优化器，根据解析器结果生成最佳的执行计划。
- 选择合适的存储引擎进行操作数据（图中是 InnoDB 存储引擎）
InnoDB执行流程将需要操作的数据从磁盘文件中查询出来，放入缓冲池（Buffer Pool）。如果缓冲池中已经存在则不需要查询磁盘。（查询SQL此时会返回结果）
将 旧数据 写入 undo log。（undo log 用于事务回滚）
更新缓冲池中的数据。
写入 Redo Log Buffer。（redo log 主要用于 MySQL 突然宕机的数据恢复）（此时写入的日志存储于内存中）
-
redo log 写入磁盘的时机。
innodb_flush_log_at_trx_commitmysql 的这个配置来控制写入 redo log 的时机 默认 为 1
0时 事务提交时，不写入redo 磁盘文件，而是由 InnoDB存储引擎线程来定时写入磁盘. 性能最好,但是宕机会丢失数据
1时 事务提交时，写入 redo 磁盘文件。安全性最高，不会丢失数据，相对性能差。
2 事务提交时，不写入redo 磁盘文件，而是写入 os cache。然后再从os cache 写入 磁盘文件。性能比1好，但是比0差，如果机器宕机则会丢失数据。 -
写入 binlog 日志. (用于数据库恢复和主从复制)
sync_binlog控制binlog写入磁盘策略 默认=0
=0时先写入 OS cache 然后写入磁盘
=1直接写入磁盘 redo log 与 bin log 全部写入成功后提交事务完成
以上就是大概 SQL 的运行流程。主要描述的是 InnoDB 存储引擎。
