1、查询过程
1、mysql有线程池接收客户端请求
2、线程获取到sql语句后会封装成sql接口
3、解析器 会将sql语句解析成它认识的对象
4、经过解析后,查询优化器会将这个对象 选择一种最优的执行计划进行封装。怎么查询最优,从哪里查询
5、经过优化后的语句调用执行器进行执行,执行器去存储引擎进行执行sql语句
2、insert/update时如何保证一定成功
mysql中数据最终是都会落入磁盘中
2.1 buffer pool
buffer pool是数据库中数据的缓存区,因为数据的查询不可能每次都要对磁盘进行随机读写那么性能肯定是相当慢了,因此在磁盘之上我们把一部分数据缓存到buffer里,这样每次查询时会先在buffer里查,如果buffer里没有,才会去数据库里查。
buffer pool也是有大小的,默认128M,我们可以在mysql配置文件里进行设置。
2.2 undolog、redolog、binlog
既然我们有个buffer缓冲区,那么一定就会带来一个问题,缓冲区数据和磁盘数据一致性问题。比如:更新数据时,是先更新buffer还是先更新磁盘,期间如果宕机了,怎么办?并发时怎么解决数据不一致? 这就和redis缓存和mysql的一致性问题差不多,但是mysql一般作为我们的数据最终定性的存储,它本身内部机制不允许出现缓存区数据不一致问题。为了解决这个问题,提出了undo和redo两种日志机制
简单总结:
- undolog 是存储本次更新前的数据,为了宕机或者事务出错可以回滚
- redolog 是记录本次更新需要更新哪些字段为哪些数据,在事务提交前也是存储在内存中,当提交事务时会落盘
- 上面两个日志是innodb特有的日志,因为innodb 是事务型存储引擎,binlog 是mysql级别的日志。我们一般配置 5 6 7都完成才算本次事务执行成功。
写commit标记是最终的步骤,如果期间任何一步失败了,都是事务失败,没有commit标记。那么恢复的时候就不会恢复redolog里的数据
写日志是使用的磁盘顺序读写,这样io操作速度更快。