change buffer使用

主要是给同一页的随机写攒批 1. 只影响不存在唯一索引的插入 2. 如果插入后就需要读取，那么最好关闭change buffer

索引是如何实现mvcc呢？

索引没有undolog，因此索引需要回表，通过回表得到数据的undolog，然后判定索引条目是否有效。但是如果索引本身不带事务id，那么如何知道其属于哪一个版本呢？如果每个索引条目都需要回表才能确定是否有效，那么全索引扫描不就是全表扫描了吗？如果主键变更索引又要如何处理？

https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html?open_in_browser=true

似乎是，二级索引的数据也是一样不删除，而是标记为删除，但是仍然存留在二级索引的b+树上，每个索引页会记录最近更新的事务id。而如何确定数据是否有效呢，回表,回表，回表，重要的事情说三遍，只有回表访问版本链才能知道readview是否能够看到这条记录的这个版本

If a secondary index record is marked for deletion or the secondary index page is updated by a newer transaction, the covering index technique is not used. Instead of returning values from the index structure, InnoDB looks up the record in the clustered index.

删除或创建主键会重建表

由于当前系统中没有比undolog更早的readview才能删除undolog。因此应当避免长事务来防止undolog大量占用磁盘和buffer pool。

undolog使得记录能够往回回滚，使得mvcc读取到历史版本的数据

redolog是innodb引入保证crash-safe的。而binlog则是mysql的归档日志，可以提供备份、从节点复制等功能。为了保证redolog与binlog的一致性，通常需要两阶段提交，从而防止mysql的数据与binlog数据不一致。主要在于需要保证事务的redolog状态至少为prepare状态，且binlog完整(如果当前redolog处于提交状态，则事务直接是有效的)

redolog是循环写的，只需要读取需要修改的数据(页)然后根据页的状态生成物理修改日志。使用redolog则无需直接去随机写修改磁盘页，而转变为了“顺序写redolog”

连接使用的一些内存资源只有在连接断开时释放。因此对于大查询或者长期使用的连接可以定期释放或者在5.7+执行mysql_reset_connection