MySQL-12-innodb引擎补充
作者：互联网
innodb引擎保证事务的ACID
概念
redo log ---> 重做日志 ib_logfile0~1 50M 轮询使用
redo log buffer ---> redo内存区域
ibd ---> 存储数据行和索引
buffer pool ---> 缓冲区池,数据和索引的缓冲
LSN: 日志序列号
在磁盘数据页（ibd）,redo文件,buffer pool,redo buffer中有LSN号
MySQL每次数据库启动,都会比较磁盘数据页和redolog的LSN,必须要求两者LSN一致数据库才能正常启动
WAL : write ahead log 日志优先写的方式实现持久化
脏页 : 内存脏页,内存中发生了修改,没写入到磁盘之前,我们把内存页称之为脏页
CKPT: Checkpoint,检查点,就是将脏页刷写到磁盘的动作
TXID: 事务号,InnoDB会为每一个事务生成一个事务号,伴随着整个事务.
redo log
提示
Atomic（原子性）
所有语句作为一个单元全部成功执行或全部取消。不能出现中间状态。
Consistent（一致性）
如果数据库在事务开始时处于一致状态，则在执行该事务期间将保留一致状态。
Isolated（隔离性）
事务之间不相互影响。
Durable（持久性）
事务成功完成后，所做的所有更改都会准确地记录在数据库中。所做的更改不会丢失
1 Redo是什么？
redo 顾名思义“重做日志”，是事务日志的一种
2 作用是什么？
在事务ACID过程中，实现的是“D”持久化的作用。对于AC也有相应的作用
3 redo日志位置
redo的日志文件：iblogfile0 iblogfile1
4 redo buffer
redo的buffer:数据页的变化信息+数据页当时的LSN号
LSN：日志序列号 磁盘数据页、内存数据页、redo buffer、redolog
5 redo的刷新策略
commit;
刷新当前事务的redo buffer到磁盘
还会顺便将一部分redo buffer中没有提交的事务日志也刷新到磁盘
6 MySQL CSR——前滚
MySQL: 在启动时,必须保证redo日志文件和数据文件LSN必须一致, 如果不一致就会触发CSR,最终保证一致
情况一:
我们做了一个事务,begin;update;commit.
1.在begin ,会立即分配一个TXID=tx_01.
2.update时,会将需要修改的数据页(dp_01,LSN=101),加载到data buffer中
3.DBWR线程,会进行dp_01数据页修改更新,并更新LSN=102
4.LOGBWR日志写线程,会将dp_01数据页的变化+LSN+TXID存储到redobuffer
5.执行commit时,LGWR日志写线程会将redobuffer信息写入redolog日志文件中,基于WAL原则,
在日志完全写入磁盘后,commit命令才执行成功,(会将此日志打上commit标记)
6.假如此时宕机,内存脏页没有来得及写入磁盘,内存数据全部丢失
7.MySQL再次重启时,必须要redolog和磁盘数据页的LSN是一致的.但是,此时dp_01,TXID=tx_01磁盘是LSN=101,dp_01,TXID=tx_01,redolog中LSN=102
MySQL此时无法正常启动,MySQL触发CSR.在内存追平LSN号,触发ckpt,将内存数据页更新到磁盘,从而保证磁盘数据页和redolog LSN一值.这时MySQL正常启动
以上的工作过程,我们把它称之为基于REDO的"前滚操作"
undo log
1 undo是什么？
undo 顾名思义“回滚日志”
2 作用是什么？
在事务ACID过程中，实现的是“A” 原子性的作用
另外CI也依赖于Undo
在rolback时,将数据恢复到修改之前的状态
在CSR实现的是,将redo当中记录的未提交的时候进行回滚.
undo提供快照技术,保存事务修改之前的数据状态.保证了MVCC,隔离性,mysqldump的热备
锁
“锁”顾名思义就是锁定的意思
“锁”的作用是什么？
在事务ACID过程中，“锁”和“隔离级别”一起来实现“I”隔离性和"C" 一致性 (redo也有参与)
悲观锁:行级锁定(行锁)
谁先操作某个数据行,就会持有<这行>的(X)锁.
乐观锁: 没有锁
隔离级别
影响到数据的读取,默认的级别是 RR模式
transaction_isolation 隔离级别(参数)
RU: 读未提交,可脏读,一般不容易出现
RC: 读已提交,可能出现幻读,可以防止脏读
RR: 可重复读,功能是防止"幻读"现象,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁)
SR: 可串行化,可以防止死锁,但是并发事务性能较差
补充: 在RC级别下,可以减轻GAP+NextLock锁的问题,但是会出现幻读现象,
一般在为了读一致性会在正常select后添加for update语句.但是,请记住执行完一定要commit 否则容易出现所等待比较严重
例如:
mysql> select * from city where id=999 for update;
mysql> commit;
innodb引擎参数补充
1.存储引擎相关
1.1 查看
show engines;
show variables like 'default_storage_engine';
select @@default_storage_engine;
1.2 如何指定和修改存储引擎
(1) 通过参数设置默认引擎
(2) 建表的时候进行设置
(3) alter table t1 engine=innodb;
2. 表空间
2.1 共享表空间
innodb_data_file_path
一般是在初始化数据之前就设置好
例子:
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend
2.2 独立表空间
show variables like 'innodb_file_per_table';
3. 缓冲区池
3.1 查询
mysql> select @@innodb_buffer_pool_size;
mysql> show engine innodb status\G
innodb_buffer_pool_size = 24G
一般建议最多是物理内存的 75-80%
4. innodb_flush_log_at_trx_commit (双一标准之一)
4.1 作用
主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，取值分别为0、1、2三个。
4.2 查询
select @@innodb_flush_log_at_trx_commit;
4.3 参数说明:
1，每次事物的提交都会引起日志文件写入、flush磁盘的操作，确保了事务的ACID；flush把操作系统文件的缓存fsync到物理磁盘
0，表示当事务提交时，不做日志写入操作，而是每秒钟将log buffer中的数据写入文件系统缓存并且每秒fsync磁盘一次；
2，每次事务提交引起写入文件系统缓存，并且每秒钟完成一次fsync磁盘操作
5. Innodb_flush_method=(O_DIRECT,O_DSYNC,fsync)
5.1 作用
控制的是 log buffer 和data buffer 刷写磁盘的时候是否经过文件系统缓存
5.2 查看
show variables like '%innodb_flush%';
5.3 参数值说明
O_DIRECT: 数据缓冲区写磁盘,不走OS buffer #建议使用这个参数
fsync: 日志和数据缓冲区写磁盘,都走OS buffer #默认参数
O_DSYNC: 日志缓冲区写磁盘,不走OS buffer
5.4 使用建议
最高安全模式
innodb_flush_log_at_trx_commit=1
Innodb_flush_method=O_DIRECT
最高性能:
innodb_flush_log_at_trx_commit=0
Innodb_flush_method=fsync
6. redo日志有关的参数
innodb_log_buffer_size=16777216 # redo buff 大小，字节为单位
innodb_log_file_size=50331648 # redo日志文件大小，字节为单位
innodb_log_files_in_group = 3 # redo日志的个数，默认是2个
脏页刷写策略
innodb_max_dirty_pages_pct=75 # 当脏页占内存75%，会立即触发往磁盘写数据
还有哪些机制会触发写磁盘?
CSR
redo满了
标签：12,buffer,LSN,innodb,MySQL,磁盘,日志,redo 来源： https://www.cnblogs.com/lichengguo/p/15035612.html