InnoDB
MySQL8.0之后默认存储引擎为InnoDB
MySQL引擎区别 | InnoDB | MyISAM |
---|---|---|
事务支持 | 支持 | 不支持 |
数据行锁定 | 支持 | 不支持 |
外键约束 | 支持 | 不支持 |
全文索引 | 不支持 | 支持 |
表空间大小 | 较大,约为MyISAM2倍 | 较小 |
InnoDB主要组成
- Buffer Pool缓冲池
- undo日志文件
- redo log buffer + 日志文件
- IO线程
update工作流程
- 从磁盘文件加载数据到
BufferPool
缓冲池 - 写入数据的旧值到
undo日志文件
便于回滚 - 进行update语句操作,更新BufferPool缓冲池数据
- 写redo日志到
Redo Log Buffer
,说明修改操作 - 提交事务时InnoDB把
redo日志
写入磁盘文件保存 - 提交事务时执行器把
binlog日志
写入磁盘文件保存,并在redolog添加commit标记 - MySQL有一个后台的
IO线程
,会在之后某个时间里,随机的把内存buffer pool中的修改后的脏数据给刷回到磁盘上的数据文件里去
Q&A
🔥step6之前MySQL挂掉了会有问题吗?
Step6之前未提交事务,此时挂掉会报MySQL异常,事务执行失败,所以不会有问题
🔥stpe5要设置innodb_flush_log_at_trx_commit为1,redolog才会写到磁盘文件
- 0:提交事务的时候,不会把redo log buffer里的数据刷入磁盘文件的
- 1:提交事务的时候,redo log buffer里的数据刷入磁盘文件,事务提交后MySQL挂了可以用该文件恢复(最常用)
- 2:提交事务的时候,把redo日志写入磁盘文件对应的os cache缓存里去
stpe6要设置sync_binlog为1,binlog才会写到磁盘文件,否则也会写到os cache
🔥为什么不能直接更新磁盘上的数据?
磁盘随机读写的性能是最差的,所以直接更新磁盘文件,必然导致我们的数据库完全无法抗下任何一点点稍微高并发一点的场景
🔥redolog与binlog的区别
- redo log是在InnoDB存储引擎产生,而binlog是MySQL数据库产生的
- binlog 是用作人工恢复数据,redo log 是 MySQL 自己使用,用于保证在数据库崩溃时的事务持久性。
- redo log 文件是固定大小的,是循环写的,写满了会从头继续写,而 binlog 是追加写的,写满了再新建文件接着写。