事务的ACID特性
A-原子性
事务一个原子操作单元，对于数据的修改，要么全部执行，要么全部执行
以下有两种情况需要分析？
事务提交了，如果此时Buffer Pool的脏页没有刷盘，如何保证修改的数据生效？
如果事务没有提交，但是Buffer Pool脏页刷盘了，如果保证不该存在的数据撤销？
以上问题，需要引入Undo和Redo的概念，每次写事务，都会修改BudfferPool,从而产生相应的Redo和Undo日志，再刷新到磁盘之前，这些日志信息都会先写入到日志文件中
C-一致性
事务一旦提交，它对数据库中的数据的改变应该是永久性的，后续的操作或者故障不应该对其有任何的影响，不会丢失
I-隔离性
一个事务的执行不应该被其他的事务干扰
InnoDB支持的隔离性有四种，隔离级别从低到高，读未提交，读提交，可重复读，可串行化
锁和多版本控制技术就是用于保障隔离性
D-持久性
事务开始之前和是事务结束之后，数据库的完整性限制未被破坏
脏读：一个事务读到了另一个事务修改但未提交的数据
不可重复读：一个事务中多次读取同一行记录不一致，后面读取的和前面读取的不一致
幻读：一个事务中多次按照相同的条件查询，结果不一致，后续查询的结果和前面查询的结果不同，多了或少了行记录
处理事务的相关方案:
第一种是排队，完全按照顺序执行所有事务的数据库操作，不需要加锁，也就是全局排队，效果就是某一时刻只能处理一个事务操作
第二种是排他锁，先进入的事务独占数据项，其他事务被阻塞，等待前面的事务释放锁
第三种是读写锁，细化锁的颗粒度，区分读操作和写操作，让读和读之间不加锁，即可以实现读和读的并行，但是读和写，写和读，写和写几种情况之间还是需要加排它锁的
第四种MVCC,实现了对读和读并行，读和写并行，写和读并行，但是为了保持一致性，写和写并行没法实现
MVCC实现原理
目前只能在读已经提交的和可重复读两种隔离级别下工作
在MVCC并发控制中，读操作可以分为两类:快照读和当前读
数据库的事务隔离级别越高，并发问题就越小，但是并发处理能力就越差，事务的隔离级别，针对的是InnoDB引擎，支持事务的功能
查询mysql数据库的事务隔离级别的命令
show variables like 'tx_isolation'
手动设置事务的隔离级别
设置隔离级别为读未提交 set tx_isolation='READ-UNCOMMITTED'
设置隔离级别为读已提交 set tx_isolation='READ-COMMITTED'
设置事务隔离级别为重复读 set tx_isolation='REPEATABLE-READ'
设置事务隔离级别为序列化 set tx_isoaltion='SERIALIZABLE'
分别对四种事务的隔离级别进行说明
读未提交 处理更新丢失的问题，但是会造成脏读，意思就是读取其他会话中未提交的但是已经修改的数据
读已提交 只能读取其他会话中已经提交的数据，解决了脏读问题
以上对事务的隔离级别，锁，,mvcc进行了简单说明，下面介绍使用说明，
事务的隔离级别底层是对锁和mvcc的一种封装，类似对于事务并发控制的整体解决方案，只是隐藏了底层细节
锁是事务并发控制的基础，事务隔离性使用锁实现，不同的操作使用不同的锁，解决不同的读写操作问题
对于用户来说，首先使用隔离级别处理问题，当隔离级别无法处理问题时，然后考虑使用锁
mysql的默认隔离:可重复读
mysql查询事务隔离级别 show variables like 'tx_isolation'
oracle的默认隔离级别:读已提交
构建一个session处于事务中
declare trans_id Varchar2(100); begin trans_id := dbms_transaction.local_transaction_id( TRUE ); end;
记得不要提交
SELECT s.sid, s.serial#,CASE BITAND(t.flag, POWER(2, 28))
WHEN 0 THEN 'READ COMMITTED'
ELSE 'SERIALIZABLE' END AS isolation_level
FROM v$transaction t
JOIN v$session s ON t.addr = s.taddr AND s.sid = sys_context('USERENV', 'SID');
常规开发使用默认的隔离级别，高并发需求中引入悲观锁，乐观锁处理问题
标签：事务,隔离,tx,isolation,介绍,提交,简单,级别 From： https://www.cnblogs.com/q202105271618/p/16504134.html