mysql的执行逻辑与日志

mysql的执行整体分为两层
一条sql语句的执行过程如下：

数据库的连接：mysql -h -p -u -p
show PROCESSLIST 查看我们当前的连接。
长连接：是指我们在连接成功之后，如果客户端持续有请求，则会使用同一个连接。
短连接：是指执行完几次连接之后，就断开了。下次连接，会创建一个新的连接。
连接是一项比较耗用时间的操作，因此需要尽量使用长连接。
mysql执行过程中，临时用的内存是管理在连接对象中的，这些资源只有在连接断开哦之后才能释放，因此，若果有很多长连接会造成内存溢出即OOM。
怎么解决呢？

1. 定期断开长连接，程序里边可以判断执行一个占用内存较大的查询之后，断开连接。
2. 2.mysql5.7之后，可以再执行一个较大的查询操作之后，通过执行mysql_reset_connection来重新初始化连接资源，这个过程不需要重连和权限校验，但会讲连接恢复到刚刚创建完时的状态。类似于做了一个清空缓存的操作。
   . 缓存器：查询缓存，不建议使用，因为一旦表发生变动，有这张表有关的缓存都会被清空。mysql8.0之后的版本已经将缓存功能删除。

分析器：类似于java中的编译，检查语句的语法是否正确。
优化器：优化器是在表里有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联的时候，决定表的连接顺序。
执行器

mysql日志：
作用：数据恢复，数据一致性保证
mysql的日志分两块：binlog归档日志，位于server层，记录执行语句，属于逻辑记录。
redolog，inodb特有的，记录数据修改了什么？
redolog是循环写，binlog是追加写。
如何保障数据恢复？binlog日志+全库备份。
场景：今天的下午两天，你删了一张表。这时候你找到上一次的数据库全量备份，正好昨天晚上有。然后你取出昨晚备份时间点之后的binlog日志，依此执行到删表之前，ok。。

如何保证数据一致？
这就要提到两阶段提交。
update a set c=c+1 where id=2;

这里redolog的prepare和commit两个状态就是两阶段提交。

redolog用于系统重启时数据恢复
binlog用于数据恢复
如果没有两阶段提交，就会造成mysql异常重启后数据与binlog日志记录。
innodb_flush_log_at_trx_commit=1的时候，每次提交事务redo log都直接持久化到磁盘，建议设置为1，这样重启之后数据不会丢失。
sync_binlog=1的时候，每次事务提交binlog都会持久化到磁盘。