MySql整体架构
经过上述处理,SQL变成执行计划,发送给innoDB的HandlerAPI
连接池允许连接重复利用
连接池参数:
SQL解析/优化
存储引擎以及数据写入原理
Mysql存储引擎是InnoDB
IO线程用O_DIRECT方式open磁盘文件,即不使用OS内核提供的缓存PageCache.而使用InnoDB自己的缓存机制.
Redo/UndoLog都只针对UPDATE(广义,任何写操作)语句
RedoLog
RedoLog是为了防止数据库崩溃重启造成的BufferPool中的数据丢失.
RedoLog刷盘策略1:
每次在事务提交前,都会将"更新写入信息"写到内存RedoLogBuffer中,与此同时,添加到OS的内存中(Write操作),并立刻进行刷盘(flush)
BinLog
提供的功能:1.变更历史查询2.数据库备份和恢复3.主从复制
会在RedoLog写入的同时进行BinLog刷盘操作,刷盘成功后会告知Redo日志事务"已提交",Redo日志也会打入commit标志
MySql存储结构
页是内存和磁盘交互的最小单元,大小通常为16KB
行长度不固定
新建表时,会创建6个Page,16*6=96KB大小.这些页会被放在表空间中叫碎片区的地方.后续再申请Page直到构建32个零散页后,后续每次都会申请完整的区
段是一种逻辑概念
事务
事务是数据库系统的最小操作单元(必须commit或abort/rollback).而平时我们写的一条条单独的SQL语句,如SELECT * FROM A,默认这一条语句就是一个事务.
保证A(原子性)的方法:UndoLog,实现回滚机制
MVCC
MVCC是一种乐观锁的体现
四步判断规则:
ReadView维护4个数据:1.活跃事务列表中,即统计当前所有没有提交的事务 2.minId(即活跃事务列表中ID最小值) 3.maxID(下一个待分配的事务ID,即该id的事务还未开始,活跃事务列表中ID最大值+1) 4.生成ReadView的当前事务id (查看当前undolog中版本id的作用实际上是查看该数据最新修改是由哪个事务修改，并从此得到一个undolog链)
1.当前undolog中版本id==当前事务版本id,意味着读取自己修改的数据,当然可以访问
2.若不等,当前undolog中版本id<minID,说明在生成ReadView前已提交,可以访问.
3.若不等,当前undolog中版本id>maxID,说明在生成ReadView后才开启,不能访问.需要沿着undolog链找下一条undolog
4.若当前undolog中版本id in活跃事务列表中，则代表未提交， 若是读已提交隔离级别（这就是MVCC实现读已提交的机制），这该数据也不能读取，则遍历undolog链的下一个undolog记录.若当前undolog中版本id not in活跃事务列表中（介于min和max之间）,则说明在生成ReadView时已提交,可以访问.
解决脏读的方法:在事务创建每一个查询时都创建一个ReadView
解决不可重复读的方法:在事务创建第一个查询时创建一个ReadView,后续每次查询只用这一个ReadView
MVCC不可解决幻读问题.
Mysql锁
锁的分类
行锁
行锁分为排他锁（X）（相当于写锁）和共享锁（S）（相当于读写锁）
