mysql事务特性以及事务工作原理，刷盘策略（redo，undo）-mysql如何去保证事务的ACID特性

事务的ACID特性

---作用是什么？
影响了DML语句（insert update delete 一部分select）

Atomic（原子性）
所有语句作为一个单元全部成功执行或全部取消。不能出现中间状态。
Consistent（一致性）
如果数据库在事务开始时处于一致状态，则在执行该事务期间将保留一致状态。
Isolated（隔离性）
事务之间不相互影响。
Durable（持久性）
事务成功完成后，所做的所有更改都会准确地记录在数据库中。所做的更改不会丢失。

隔离级别

transaction_isolation 隔离级别(参数)
负责的是,MVCC,读一致性问题
RU : 读未提交,可脏读,一般部议叙出现
RC : 读已提交,可能出现幻读,可以防止脏读.
RR : 可重复读,功能是防止"幻读"现象 ,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁)
SR : 可串行化,可以防止死锁,但是并发事务性能较差
补充: 在RC级别下,可以减轻GAP+NextLock锁的问题,但是会出现幻读现象,一般在为了读一致性会在正常select后添加for update语句.但是,请记住执行完一定要commit
否则容易出现所等待比较严重.
RR级别：解决了不可重复读问题+幻读的现象,

不可重复读问题是由 undo的快照技术来解决。

幻读现象是由：MVCC+GAP+next-lock
例如:
[world]>select *

事务的生命周期（事务控制语句）

--事务的开始

begin; / start transaction;
说明:在5.5 以上的版本，不需要手工begin，只要你执行的是一个DML，会自动在前面加一个begin命令。

-- 事务的结束
commit：提交事务
完成一个事务，一旦事务提交成功，就说明具备ACID特性了。
rollback ：回滚事务
将内存中，已执行过的操作，回滚回去

自动提交策略（autocommit）

db01 [(none)]>select @@autocommit;
db01 [(none)]>set autocommit=0;
db01 [(none)]>set global autocommit=0;

注：
自动提交是否打开，一般在有事务需求的MySQL中，将其关闭
不管有没有事务需求，我们一般也都建议设置为0，可以很大程度上提高数据库性能

(1)
set autocommit=0;
set global autocommit=0;
(2)
vim /etc/my.cnf
autocommit=0

事务的隐式控制

--异常终止

delete from where xxxx

kill 5850692 --导致上面删除语句终止，失效

---用于隐式提交的SQL语句
begin
a
b

begin 自动提交上一个事务

set autocomit = 1

导致提交的非事务语句：
DDL语句：（ALTER、CREATE 和 DROP）
DCL语句：（GRANT、REVOKE 和 SET PASSWORD）
锁定语句：（LOCK TABLES 和 UNLOCK TABLES）

导致隐式提交的语句示例：
TRUNCATE TABLE
LOAD DATA INFILE
SELECT FOR UPDATE

开始事务流程：

1、检查autocommit是否为关闭状态
select @@autocommit;
或者：
show variables like 'autocommit';

2、开启事务,并结束事务
begin
delete from student where name='alexsb';
update student set name='alexsb' where name='alex';
rollback;

begin
delete from student where name='alexsb';
update student set name='alexsb' where name='alex';
commit;

InnoDB 事务的ACID如何保证?

10.0 一些概念

1，redo log ---> 重做日志 （前滚日志）ib_logfile0~ ib_logfile1 50M ,轮询使用（大小和个数都可以调整，使用方式二进制，轮询去写日志）
redo log buffer ---> redo内存区域(加载redo)

2，city.ibd ,order.idb...----> 存储数据行和索引
buffer pool --->数据缓冲区池,数据和索引的缓冲,

3，LSN : 日志序列号

---像git或者svn里面的版本号

磁盘数据页,redo文件,buffer pool,redo buffer

MySQL 每次数据库启动,都会比较磁盘数据页和redolog的LSN,必须要求两者LSN一致数据库才能正常启动

4，WAL : write ahead log 日志优先写的方式实现持久化

--------优先日志redo buffer数据（日志）先写到磁盘ib_logfile0,然后，buffer poll内存数据写入ibd文件

5，脏页: 内存脏页,内存中发生了修改,没来得及写入到磁盘,我们把内存页称之为脏页.

--idb 修改name="张三" lsn=100 buffer pool内存中修改name="lisi" lsn=101 此时还没来得及写入磁盘idb 就是脏页

6，CKPT:Checkpoint,检查点,就是将脏页刷写到磁盘的动作

7 ，TXID: 事务号,InnoDB会为每一个事务生成一个事务号,伴随着整个事务.

---------正常情况下，再不断电，不宕机情况下流程

redo log介绍

10.1.1 Redo是什么？
redo,顾名思义“重做日志”，是事务日志的一种。

10.1.2 作用是什么？
在事务ACID过程中，实现的是“D”持久化的作用（数据库down机了不丢失数据）。对于AC也有相应的作用

10.1.3 redo日志位置
redo的日志文件：iblogfile0 iblogfile1

10.1.4 redo buffer
redo的buffer:数据页的变化信息+数据页当时的LSN号

LSN：日志序列号磁盘数据页、内存数据页、redo buffer、redolog

redo的刷新策略

commit;
刷新当前事务的redo buffer到磁盘
还会顺便将一部分redo buffer中没有提交的事务日志也刷新到磁盘

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 回滚日志

11.2.1 undo是什么？

undo,顾名思义“回滚日志”

11.2.2 作用是什么？

在事务ACID过程中，实现的是“A” 原子性的作用
另外CI也依赖于Undo
在rolback时,将数据恢复到修改之前的状态
在CSR实现的是,将redo当中记录的未提交的时候进行回滚.
undo提供快照技术,保存事务修改之前的数据状态.保证了MVCC,隔离性,mysqldump的热备

11.3 概念性的东西:
redo怎么应用的
undo怎么应用的
CSR(自动故障恢复)过程
LSN :日志序列号
TXID:事务ID
CKPT(Checkpoint)

innodb几个重点参数：

缓冲区池

select @@innodb_buffer_pool_size;
show engine innodb status\G
innodb_buffer_pool_size 
一般建议最多是物理内存的 75-80%

innodb_flush_log_at_trx_commit (双一标准之一)

作用：

主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，取值分别为0、1、2三个。
控制了redo buffer 刷写策略，是一个安全参数，是在5.6版本以上默认的参数

select @@innodb_flush_log_at_trx_commit;

#innodb_flush_log_at_trx_commit=1

参数说明：

1，每次事物的提交都会引起日志文件写入、flush磁盘的操作，确保了事务的ACID；flush 到操作系统的文件系统缓存 fsync到物理磁盘

0，表示当事务提交时，不做日志写入操作，而是每秒钟将log buffer中的数据写入文件系统缓存并且秒fsync磁盘一次；

2，每次事务提交引起写入文件系统缓存,但每秒钟完成一次fsync磁盘操作。

制了redo buffer 刷写策略，是一个安全参数，是在5.6版本以上默认的参数

参数功能

1：每次事务提交，都会立即刷下redo到磁盘（redo buffer --每次事务-->os buffer（操作系统缓存） --每次事务--写入磁盘）
0：表示当事务提交时，不立即做日志写入操作（redo buffer --每秒-->os buffer （操作系统缓存）--每秒--磁盘）
2：每次事务提交引起写入文件系统缓存（redo buffer --每事务-->os buffer（操作系统缓存） --每秒--磁盘）

Innodb_flush_method=(O_DIRECT, fdatasync)

作用：

控制了 redo buffer 和 data bufffer 刷写磁盘方式

控制的是,log buffer 和data buffer,刷写磁盘的时候是否经过文件系统缓存
show variables like '%innodb_flush%';
O_DIRECT :数据缓冲区写磁盘,不走OS buffer（操作系统缓存）
fsync :日志和数据缓冲区写磁盘,都走OS buffer（操作系统缓存）
O_DSYNC :日志缓冲区写磁盘,不走 OS buffer（操作系统缓存）

最大安全模式：
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT

最大性能模式：
innodb_flush_log_at_trx_commit=0
innodb_flush_method=fsync

## 4.3 关于redo设置
innodb_log_buffer_size= 128M 业务系统CPU压力有关
innodb_log_file_size=256 一般是1-2倍
innodb_log_files_in_group = 3 3-4组

redo日志有关的参数

innodb_log_buffer_size=16777216 内存大小
innodb_log_file_size=50331648  文件大小
innodb_log_files_in_group = 3