mysql innodb事物学习笔记

mysql innodb事物学习笔记

1. 事物是工作的原子单元，可以提交或回滚。当事物对数据库进行更改时，要么在事物提交时都成功，要么在事物回滚时所有更改都被撤销。
   由innodb实现的数据库事物，满足我们总所周知的ACID，及原子性，一致性，隔离性和持久性。

事物提交或回滚
START TRANSACTION 或者BEGIN start a new transaction.
Mysql 事物操作

START TRANSACTION READ WRITE;
select * from stu_user where id = 1;
update stu_user set age = age+1 where id  = 1;
ROLLBACK;
COMMIT;

在MySQL里面，就是每个语句，在没有BEGIN TRANSACTION 语句的时候，会默认使用BEGIN TRANSACTION READ WRITE, commit包围。并且不能使用rollback来回滚，只有发生了错误才会回滚。
查询是否开启了会话
show session VARIABLES like ‘autocommit’ ;
show global variables like ‘autocommit’ ;

DDL 语句不能 回滚。
SAVEPOINT回滚点， 设置回滚点。
例：

START TRANSACTION READ WRITE;
	select * from stu_user where id = 1;
	update stu_user set age = age+1 where id  = 1;
	SAVEPOINT point_one
	update stu_user set age = age+1 where id  = 1;
	ROLLBACK point_one
ROLLBACK;
COMMIT;

– 查看存在的事物

select * from information_schema.INNODB_TRX
官网--
https://dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-trx-table.html

2.ACID模型
ACID 模型是一组数据库 强调可靠性方面的设计原则 对于业务数据和任务关键型应用程序非常重要。MySQL 包括存储等组件 引擎紧密遵循 ACID 模型，因此数据不是 损坏，结果不会因特殊条件而扭曲 例如软件崩溃和硬件故障。当您依赖 符合 ACID 标准的功能，您无需重新发明 一致性检查和崩溃恢复机制。在以下情况下 您有额外的软件保护措施、超可靠的硬件或 可以容忍少量数据丢失或 不一致，可以调整MySQL设置来交易一些 ACID 可靠性可实现更高的性能或吞吐量

•	A: atomicity.
•	C: consistency.
•	I:: isolation.
•	D: durability

A: atomicity. 原子性
就是我们的多个操作是一起执行的，主要涉及的是innodb存储引擎的事物，
多个或单个操作语句都是一个事物，来保证用户想要一起提交哪些语句，或者回滚那些语句。
主要是rollback ， commit， autocommit来保证原子性。
C: consistency.
一致性方面 模型主要涉及内部处理 保护数据免受崩溃
所谓一致性，就是保证数据的一致，也就是保证数据的不丢失，不会因为突然的断电导致数据与想要的数据不一致。
I:: isolation.
ACID模型的隔离方面主要涉及事务，特别是应用于每个事务的隔离级别
自动提交设置。
Innodb锁的机制
事物的隔离级别
D: durability
持久性，就是我们的数据要尽可能要同步到磁盘，防止异常丢失，Innodb去保证磁盘一场主要体现在

1. 双写保证内存同步到磁盘，就算page损坏的情况下也能恢复
2. Redolog的同步机制设置
3. Binlog的同步机制设置
4. 独立表空间或系统表空间设置

3.事物的隔离级别
官网地址： https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html
事务隔离是数据库的基础之一 加工。隔离是首字母缩略词 ACID 中的 I;隔离级别为 微调性能和性能之间平衡的设置 结果的可靠性、一致性和重现性 多个事务正在进行更改并执行查询
InnoDB提供所有四个事务隔离 SQL：1992 标准描述的级别：读取未提交RU、读取已提交RC、可重复读取RR和可序列化serializble。默认 的隔离级别为可重复读取
在这里插入图片描述

set session TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ; -- 修改当前的会话为读未提交 RU
set session TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 修改当前的会话为读以提交 RC
set session TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- 修改当前的会话为可重复读取 RR
set session TRANSACTION ISOLATION LEVEL SERIALIZABLE; -- 串行化

数据的一致性问题
脏读： 能读取到其他线程还没有提交的数据，但是这些数据是能回滚的。
不可重复读： 在开启事物后，读取到其他事物进行修改或者删除提交的数据，
幻读： 在开启事物后， 读取到其他事物新添加的数据
当同一个查询在不同时间产生不同的行集时，就会出现所谓的幻影问题

脏读的演示
会话一

会话2 RU
会话3 RC
4.非锁定一执行读取
一致性读取意味着InnoDB使用多版本来向查询提供数据库在某个时 间点的快照。该查询查看在该时间点之前提交的事务所做的更改，而不查 看后来或未提交的事务所做的更改。
所以关键在于快照，就是在某些时间点，我创建一个快照，这个快照创建 了之后，后续同一个事务的所有读取都是读取的这个快照内容。
如果隔离级别是RR，则在第一次一致性读的时候，创建快照。
如果隔离级别是RR，则每次一致性读都会创建一个新的快照。
这里的快照其实不是真正意义的将数据存储了一份，而是一个readView的 数据结构保存了某些信息，然后通过对这些信息的判断来达到不会读到最 新数据的目的

m_low_limit_id： 即将要分配的下一个事务ID
m_up_limit_id： 所有存活的（没有提交的）事务ID中最小值
m_creator_trx_id：创建这个readView的事务ID
m_ids： 创建readView时，所有存活的事务ID列表

判断数据是否可见的逻辑

1. 如果数据的DB_TRX_ID < m_up_limit_id, 都小于存活的事务ID了，那么 肯定不存活了，说明在创建ReadView的时候已经提交了，可见。

2. 如果事物DB_TRX_ID >= m_up_limit_id， 大于我即将分配的事物ID，那么表明修改这条数据的事物是在创建了ReadView之后开启的，不可见。

3. 如果 m_up_limit_id<= DB_TRX_ID< m_low_limit_id, 表明修改这条数据 的事务在第一次快照之前就创建好了，但是不确定提没提交，判断有没 有提交，直接可以根据活跃的事务列表 m_ids判断
   a) DB_trx_ID 如果在m_ids中，表明在创建readView时还没提交。
   b) DB_trx_ID如果不在m_ids ,表明在创建readView中已经提交，那个数据可见。

4. Undolog查询以往日志
   在提交之前，这些操作都会进行undolog记录。那么这些数据对应的 undoLog是怎么样的？其实很简单，如果是添加数据，回滚把这条记录删 除；如果是删除数据，回滚的时候，把删除的重新插入；如果是修改数 据，那么把旧值记录下来，然后回滚到以前的值。
   事物回滚，我就可以根据undolog的版本中的事物ID，回滚到以前的数据。