数据库通常借助日志来实现事务，常见的有undo log、redo log，undo/redo log都能保证事务特性，这里主要是原子性和持久性，即事务相关的操作，要么全做，要么不做，并且修改的数据能得到持久化
redo log(重做日志/物理日志):提供前滚操作(commit之后一定会被写入磁盘),保证事务的持久性
undo log(回退日志/逻辑日志) :提供回滚操作(rollback 时能回到事务执行之前),保证事务的一致性
-
redo log 和 undo log 是保证本地事务的，bin log 是用于主从复制的
-
MVCC: 读不加锁，读写不冲突 事务版本号
会保存某个时间点上的数据快照。这意味着事务可以看到一个一致的数据视图，不管他们需要跑多久。这同时也意味着不同的[事务]在同一个时间点看到的同一个表的数据可能是不同的(读写排斥问题): 读取版本控制中的历史数据
在 READ COMMITTED 和 REPEATABLE READ 隔离等级之下才会使用 MVCC
可重复读事务隔离级别下，对于快照数据，非锁定一致读总是读取事务开始时的行数据版本
READ COMMITED 事务隔离级别下，总是读取最新的快照数据。
update语句中的where查询 语句 读取的都是最新的快照数据，最新的提交数据（无论在RR级别还是在RC级别都是这样的机制）
select语句中的where查询语句（不加 共享锁或排他锁的情况下）RR级别下在同一个事务中，读到的数据是事务刚开始是的快照数据（不会幻读，同一查询语句在同一事务中得到结果相同）或者是在本事务中对数据进行的最新修改，RC级别下，同一个事务中读到的是当前最新的快照版本数据（其它事务对这数据已提交的修改，会出现幻读）或者是在本事务中对数据进行的最新修改。
update语句相当于获取排他锁，未获得锁的事务只能等待。
ReadView(快照):
在innodb中(默认repeatable read级别), 事务在begin/start transaction之后的第一条select读操作后, 会创建一个快照(read view), 将当前系统中活跃的其他事务记录记录起来;
-
在innodb中(默认repeatable committed级别), 事务中每条select语句都会创建一个快照(read view)
MVCC 存在的问题: 读取旧版本数据,并以此来更新数据,导致更新丢失: 写写冲突问题
-
行锁:只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
事务级行锁: 执行更新语句时加锁,事务结束时解锁
可重复读的MVCC机制: 事务内两次相同读取的版本号一致
-
事务可能读到的数据不是最新的,需保证只有是最新的数据才能被更新:MVCC+锁
可重复读级别下: mvcc 快照读取的可能为旧数据,以旧数据进行更新时,更新操作会获取到当前读新数据,只需要保证新旧数据版本号一致才能更新,即可避免更新丢失问题,简单来说:不提供旧版本数据的写操作
可重复读的底层原理: 排它锁+MVCC 避免了第二类更新丢失问题
//查询语句 + 排他锁 : 一个事务内先查询后更新,可以通过这个方法简单实现互斥 select * from demo where id = 1 for update; -
间隙锁机制:幻读 next-key锁其实包含了记录锁和间隙锁，即锁定一个范围，并且锁定记录本身，InnoDB默认加锁方式是next-key 锁
