标签：next llb set 客户端 account database 不同 isolation 开始
事务ACID
* 原子性（atomicity）一个事务必须被视为一个不可分割的最小工作单元，整个事务中所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作
* 一致性（consistency）数据库总是从一个一致性的状态转换到另外一个一致性的状态，保持完整性约束。
* 隔离性（isolation）一个事务所做的修改在最终提交以前，对其他事务是不可见的
* 持久性（durability）一旦事务提交，则其所做的修改就会永久保存到数据库中
四种隔离级别
* READ UNCOMMITTED（未提交读），事务中的修改，即使没有提交，对其他事务也都是可见的，
* READ COMMITTED（读已提交），大多数数据库系统的默认隔离级别，事务中的修改在提交前对其他事务不可见。也叫不可重复读，有可能出现幻读
* REPEATABLE READ（可重复读），是InnoDB的默认事务隔离级别，标准的RR，不能解决幻读问题，但InnoDB的RR实现和标准不同，通过next-key和mvcc解决了幻读问题
* SERIALIZABLE（可串行化）最高级别，通过强制事务串行执行，避免了幻读问题，会在读取的每一行数据上都加锁，可能导致大量的超时和锁争用的问题
丢失更新：A回滚时，把B已提交的数据丢失掉，X锁或业务层mvcc mvcc貌似不行？
覆盖更新：A提交时，把B已提交的数据覆盖掉，读-改-写
解决办法：原子写，set v=v+1，或者X锁或业务层mvcc
脏读：事务A里读到未提交的事务B内修改后的值，然后B回滚，或者B改了多条记录，A只读了部分
隔离级别 read uncommitted
之所以会出现脏读，是因为B修改后提交前就释放了X锁，
RC解决脏读的方法就是B提交后才释放X锁，提交前也可以读，读的是修改前的快照
不可重复读：事务A里第一次读数据后，事务B修改了该数据并提交，
事务A第二次读该数据和第一次不一样。隔离级别 read committed
幻读：事务A里第一次读数据，select .. where id<7，事务B添加id=5的数据并提交，
事务A再读数据，会读到id=5的数据。隔离级别 read committed
在标准的RR下，A再次读数据，即使读不到id=5，A想添加id=5的数据也是会失败的
或者A对满足读条件的一堆数据进行修改，逐条写回数据库，
再次检查数据，会发现有满足条件且未修改的数据
而在innoDB的RR实现下，事务A通过加X锁：select .. where id<7 for update，
可以锁住区间(负无穷，7)，阻止B添加数据，从而避免幻读
关于mvcc、RR、幻读、锁的一些文章：1 2 3 4 5 6 7
事务日志
存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘，称为预写式日志（Write-Ahead Logging）
set autocommit =0; //开启事务方法1 禁止自动提交
start transaction; //开始事务方法2 A连接 进行转账操作
update account set accmoney = accmoney -1000 where aid =1;
update account set accmoney = accmoney +1000 where aid =2;
commit; //显式提交
事务回滚
start transaction;
...
rollback; 回到事务开始时的状态
commit;
commit and chain; //提交 并新开一个事务
rollback and release; 回滚之后断开和客户端的连接
还原点
start transaction;
update...;
savepoint s1;
insert...;
savepoint s2;
rollback to savepoint s1;
release savepoint s8 删除还原点
设置隔离级别
set transaction：
标签：next llb set 客户端 account database 不同 isolation 开始
原文地址：https://www.cnblogs.com/ts65214/p/12976127.html
