事务
ACID：原子性，一致性，隔离性，持久性
并发事务的问题:
脏读：一个事务读到另一个事务还没提交的数据
不可重复读：一个事务先后读取同一条记录，但读取的数据不同
幻读：一个事务查询数据发现没有对应的数据，但是插入数据时发现又存在
解决方案：对事务进行隔离
事务级别：未提交读------读已提交(RC)------可重复读（默认级别,RR）------串行化
MVCC:
隐式字段
- DB_TRX_ID：最近修改事务id ，记录插入这条记录或最后一次i修改该记录的事务ID
- DB_ROLL_PTR:回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本
- DB_ROW_ID:隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段
readview :读视图时快照读sql执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务id
当前读：
读取是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁
快照读：
简单的select就是快照读，读取的就是记录数据的可见版本，有可能是历史数据，开启事务后第一个select语句才是快照读的地方
事务中的隔离性是如何保证的呢？
通过MVCC，多版本并发控制，维护一个数据的多个版本，使得读写操作没有冲突
它的实现主要依赖数据库中记录的隐式字段，undo log日志，readView
第一，隐藏字段，里面有事务id，来记录每一次操作的事务id，还有回滚指针，指向这一个记录的上个版本
第二，
undo log，它是回滚日志，存储老版本数据。undo log是版本链的载体，多个事务并行操作某一行记录，记录不同事物修改数据的版本，通过回滚指针串联成一个链表
最后readView解决的是一个事务查询选择版本的问题
根据它的匹配规则和当前一些事务id判断该访问哪个版本的数据
不同的隔离级别的快照读是不一样的，最终的访问结果不一样
RC：每一次执行快照读时生成ReadView
RR：仅在事务第一次执行快照读时生成ReadView，后续复用
MVCC会导致表膨胀？
会的，MVCC的多版本留存是表膨胀的根本诱因，在高更新/高删除的场景下，大量过期版本未被及时清除
解决方案：长事务是阻塞清理的关键因素，优先解决；innoDB是后台自动清理，可以监控然后确保清理线程数够
主从同步原理
MySQL主从复制的核心就是二进制日志binlog
- 主库在事务提交的时，会把数据变更记录在二进制文件Binlog
- 从库读取主库的二进制文件Binlog，写入到从库的中继日记Relay Log
- 从库的sql线程异步读入Relay log，解析并执行其中的sql操作，最后实现主从同步
一条update语句执行的过程日志顺序（同insert/delete）
Undo Log → Redo Log(Prepare) → Binlog → Redo Log(Commit)
undo log
是逻辑日志，用于记录数据被修改前的信息，保证了事务的原子性和一致性,作用包括两个：提供回滚 和MVCC 。
redo log
是重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性 ，用于在刷新脏页到磁盘发生错误的时候进行数据恢复使用
Binlog
核心保障主从复制 / 数据恢复
Redo 管物理页，Undo 管行回滚，Binlog 管行复制
undo log页支持重用
Undo Log 页支持重用 ，核心原则是先重用空闲页，后扩展新空间 ，避免 Undo 表空间无限膨胀
Purge 后台线程的清理 是 Undo 页重用的唯一前提 ，无清理则无重用；
长时读事务 是生产中 Undo 页重用率低、空间膨胀的最主要原因，优化慢 SQL 是根治问题的关键
redo log 刷盘策略
Redo Log 刷盘由 innodb_flush_log_at_trx_commit 控制，该参数是唯一核心，取值为0/1/2，生产环境禁止0，生产首选 1（默认），普通库可选 2，性能比1显著提升，避免了每次fsyn（）开销，在安全上无数据丢失，最多丢失1秒内的已提交事务。