事务和锁机制：
- 事务和锁是不同的，事务具有ACID（原子性、一致性、隔离性和持久性），锁是用于解决隔离性的一机制
- 事务的隔离级别通过锁的机制来实现。因为锁有不同的粒度，因此事务也有不同的隔离级别
- 开启事务就自动加锁
事务的隔离级别：
1. read uncommited (读取未提交内容)
所有的事务可以看到未提交事务的执行结果，读取未提交的数据又称为脏读
导致了在上个事务未决定数据是否要使用的时候，被当前数据读取到了
2. read commited （读取提交的内容）
大多数数据库的默认隔离级别是这个级别，但这个不是mysql默认的。一个事务在开始的时候只能看见已提交事务所做的改变，一个事务从开始到提交前所做的任何改变都是不可见的，除非提交。这种隔离级别也称为不可重复读，一个事务只能看到其他并发的已提交事务所做的改变。解决了脏读的问题，但是read commited 不能保证在一个事务中每次都能读到相同的数据，因为在每次读数据之后其他并发事务可能会对刚刚读到的数据进行修改
此处是因为只有在开始更新的时候才会给行数据加锁，当事务一与事务二同时操作一行数据的时候，事务一先读取数据，事务二再数据进行更新提交，事务一再去读数据，这个时候拿到的是事务二更新后的值，所以在同一事务中会读到不同的数据。
导致了 在同一个事务中读到了不同的数据
-
repeatable read （可重复度）
此隔离级别是为了解决不可重复读隔离级别（读取未提交 内容和读取提交内容）导致的问题，即一个事务多个实例并发读取事务时会看到不同的结果。可重复度描述的是一个事务在处理数据时，多次查询此数据得到的结果是一样的
repeatable read与read committed相比，解决了读取因为其他事务的执行导致当前事务读取到不一致结果的问题，但是仍然无法解决其他事务新增数据，即幻读问题，当前事务可能在第一次查询只有三条数据，但是当其他事务执行的时候会有第四条数据加入，但已经存在的数据可以保证即使其他事务修改了也不会发生改变。
CREATE TABLE `students` (
`id` bigint NOT NULL AUTO_INCREMENT ,
`name` varchar(10) CHARACTER SET utf8mb4 NOT NULL DEFAULT '' COMMENT '名字' ,
PRIMARY KEY (`id`)
)
ENGINE=InnoDB
COMMENT='学生表'
;
-
serializable（可串行化）
可串行化是最高的隔离级别，通过强制书屋排序，使之不可重读，解决欢度问题，次隔离级别会在每个读的数据上加共享锁。使用这种隔离级别会产生大量的超时现象
RC隔离和RR隔离中一致性读的区别：
根据隔离级别不同，一致性读也是不一样的。不同点在于判断是否提交的“某个时间点”？？？
对RR隔离
对一个表或者不同表进行得第一次select语句建立了该事务中一致性读的snapshot，其他的update\delete\insert语句和一致性读snapshot的简历没有关系。在snapshot事务的起始点其实是以执行第一条语句为起始点的，而不是已begin作为事务的起始点。
这句话的意思就是说建立了一致性读的snapshot之后，仅仅只是读数据的一致性，也就是说在事务中读操作会从快照中读取数据，而update\insert\delete，不会从快照中读取数据，而是去从表中实时读取数据，又因为本事务中的操作数据，对本事务中的读来说是可见的，因此如果再次读取被update\delete\insert操作的已经在快照中存在数据的时候，会读取到被修改之后的结果，而不是快照中的原始数据
对RC隔离
事务中每一次读取窦诗怡当前的时间点作为判断是否提交的是几点，也即是read its own fresh shanshot
RC 是语句级多版本（事务的多条只是语句，创建不同的ReadView），RR是事务级多版本（一个ReadView）
事务开始的时间：
一般我们会认为事务开始的时间是begin/star transaction，然而这是错误的，事务真正开始的时间是start transaction或者begin之后的第一条执行sql语句，不管是什么语句，不管成功与否
如果想要在start transaction做为事务的开始时间点，那么就需要start transaction with consistent snapshot，它的含义是在执行Start transaction的时候，同时简历本十五一致性读的snapshot，等价于执行了start transaction之后马上又执行一条select语句
所以事务开始的情况分两种：
第一种是：start transaction 在第一条语句执行的时候建立快照(read view)
第二种是：start transaction with consistent snapshot 马上建立快照（read view）
一致性读的胳膊拧不过DDL的大腿
即DDL的语句执行，会导致无法使用undo构造出正确的一致性读，一致性读和他们是无法隔离的
MVCC(multiversion concurrendy control)，多版本并发控制，提供并发访问数据库时，对事务读取到的内存做处理，用来避免写操作堵塞读操作的并发问题。
Mvcc下，读事务与写事务是分开的，互不干扰的，写事务会创建一个新的数据版本，而读事务访问时旧版本的数据，直到写事务提交，如果写事务提交后，在写事务前执行的读事务仍然未结束，那么仍然读到的是旧版本的数据，在提交之后重新开始一个新的读事务，读事务才能够读到新版本的数据。
如下：
set transaction isolation level repreatable read;
start transaction with consistent snapstot;
select k from t;
update k set k = k + 1;
select k from t;
如果在一个既有读又有更新的事务中，在事务的第一个执行语句中创建了数据库快照，在事务中读操作会一直读取这个快照中的数据，直到更新事务出现，更新事务执行的时候会创建新的快照，或者替代之前的快照，或者（数据）版本比之前的快照新，这个时候读事务再次执行会读取新的快照，而不是原来的快照。
undo:undo日志用于存放数据库被修改前的值
redo:当数据库对数据做修改的时候，需要将数据页从磁盘读到buffer pool中，然后在buffer pool中修改，那这个时候buffer pool的数据页与磁盘中的数据页不一致，称buffer pool中的数据是脏数据，如果这个时候DB服务器非正常重启，那么这些数据还在内存，未同步到磁盘，（同步到磁盘是一个随机IO），也就是会发生数据丢失，这个时候如果有一个文件可以在当buffer pool中data page的变更结束后，把相应修改记录存储到这个文件（积累了日志的是顺序IO），那么当DB数据库恢复的时候，可以根据这个文件的记录内容，重新应用数据到磁盘，数据保持一致
mvcc（数据库多版本并发控制），是指数据库中同一时刻存在多个版本的数据，比如有多个视图同时读取了数据A，有些是1，有些是2，有些是3
MVCC机制的实现，第一种是将数据记录在多个版本，将多个版本的数据都保存在数据库中，当这些不同的版本数据不再需要的时候，垃圾回收器会回收这些记录。sql server使用类似机制，不同的是，它将旧版本的数据不是保存在数据库中，而是保存在不同于主数据库的另一个temdb数据库中。第二种实现方式是，只在数据库中保存最新版本的数据，但是会在使用undo时，动态重构旧版本数据，这种方式被oracle和MySQL/innodb使用
在mysql中，实际上每条记录在更新的时候都会总是记录一条回滚操作，记录上的最新值，通过回滚操作，都可以得到前一个状态的值。
这也是为什么数据库中尽量不要用尝试无，因为尝试无意味着系统里面会存在很老的事务视图（快照），由于这些事务随时可能访问数据库里面的是任何数据，所以这个事务提交之前，数据库里面它可能用到这些回滚记录必须保留，会占用大量的存储空间
InnoDb的MVCC，通过在每行记录后面保存两个隐藏的列来实现：一个保存了行的创建时间，一个保存行的过期时间，当然这里的时间不是时间戳，而是系统版本号，每开始一个新的事务，系统版本号就会递增。在RR隔离级别下，MVCC的操作如下：
-
select操作
innodb只查找版本早于（等于）当前事务版本的数据行。可以雀斑事务读取的行，要么是事务开始之前就已经存在，或者事务自身插入或者修改的记录。
行的删除版本要么未定义，要么大于当前事务版本号。可以确保事务读取的行，在事务开始之前未删除
insert操作，将新插入的行保存当前版本号为行的版本号。
delete操作。将删除的行保存当前版本号为删除标识
update操作。变为insert和delete操作的组合，insert的行保存当前版本号为行版本号,delete则保存当前版本号为原来的行作为删除标识
