ACID
- 原子性 atomicity: undolog
- 一致性 consistency
- 隔离性 isolation: 锁、MVCC
- 持久性 durability: redolog
LOG
- slowlog: 设置具体时间将执行超时的sql记录在文件中，方便进行优化调整
- binlog：DB主从同步
- errlog: DB进程中一些错误信息
- relaylog: slaver暂存同步过来的binlog数据
- undolog: 回滚日志
- redolog:前滚日志
其中slowlog\binlog\errlog\relaylog归属于mysql server，不管选择啥engine均会存在 undolog\redolog归属于innodb engine，其他存储引擎是不包含该日志信息的
笔记概念
- WAL：write ahead log (redolog)，先顺序写日志，再调整磁盘对象写B+Tree。因为：顺序写磁盘速度远超随机写。
mysql 组提交
redolog里是一个循环写的日志
两阶段提交： 因为redolog \ binlog => redolog和binlog的数据一致性无法保证，（binlog在slave同步时和redolog不一致)，那么就存在了问题，为了解决该一致性问题，则出现了两段式提交。 引入redolog (prepare状态）
MVCC
Multi-version concurrency controll, 多版本并发控制， 是用来解决数据并发读写问题的
1、隐藏字段：对于用户不可见
- DB_TRX_ID: 创建这条记录或者最后一次修改该记录事务的ID
- DB_ROLL_ID: 回滚指针，指向上一个数据的版本
- DB_ROW_ID: 隐藏主键，如果数据表没设置PK，会生成一个6字节的ROWID
- 数据库里，事务编号是递增的
- undolog: insert\delete\update操作的时候产生方便回滚的日志
2、readview
- 读视图是在事务进行快照读的时候产生的读视图，保存的不是数据信息，而是事务的相关信息
- trx_list: 在生成readview时刻，当前系统正在活跃的事务列表
- up_limit_id: 当前活跃列表中事务ID 最小的值
- low_limit_id: 系统尚未分配的下一个事务ID
- 可见性算法？？？？
- 开始快照读的时候，开启readview
- 通过实验，readview只是生成了一次（指上面那三个变量）；后续的select操作会沿用第一次的readview
2.1 尝试将隔离级别贺readview生成开始练习
- RC: 每次都读取到其他事务已经提交的数据 ---每次读都生成readview
- RR：只是解决了不可重复读的问题 --- 在一个事务中，第一次进行快照读的时候生成readview，之后都会沿用之前的readview，而不会重新生成readview
- 隔离级别的本质是：给了user一个操作入口可以解决不可重复读的问题，本质逻辑在于MVCC
- 当前读
- 快照读
2.2 幻读
- 事务一，begin, select; 事务二：begin, insert, commit; T2,事务一，select \update；则会发生幻读
- 幻读发生的本质是：如果事务中都是快照读则不会产生幻读问题；但是快照读和当前读一起使用的时候就会产生幻读问题
