简述
- 本文都是在RR级别下讨论的
- change buffer是针对数据页的优化，减少更新操作时从磁盘随机读数据页的次数。redo log是配合缓存池减少随机写磁盘操作。
- 猜测：判断是否有锁，不需要读数据页出来，加锁需要读数据页出来
- InnoDB要更新一个数据页时，如果数据页在内存就直接更新，如果不在内存，在满足条件的情况下（不影响数据一致性、没加锁等），会将这些更新操作缓存在change buffer中。在后面的某次查询时需要访问这个数据页时，将数据页从磁盘读取到内存中，并将change buffer中与这个页有关的操作执行（这个过程成为merge），将更新应用到数据页中，通过这种方式保证数据的正确性。
- change buffer页也是写在redo log中的，以此防止change buffer中的数据丢失（这里有个疑问点，change buffer数据也会写到system table space<ibdata1>中，这个是为了做什么？）
无法使用change buffer的场景
- change buffer可以优化update、insert、delete。但是对于聚簇索引是无法起到优化作用
- 某些场景对唯一索引也无法启动优化作用。
- 如果会造成数据页分裂、合并应该也不会写入change buffer。
- 遇到了锁。
Insert流程
- 定位主键应该落入的聚簇索引、唯一索引数据页，将页读取到内存。
- 聚簇、唯一索引字段做唯一性约束校验。
- 校验通过，更新聚簇索引树数据页并对聚集索引、唯一索引记录加写锁
- 判断普通索引树是否有间隙锁，如果没有间隙锁，普通索引树数据页如果不在buffer pool就不做更新直接写入change buffer（这俩操作都会写redo log，但和此流程无关，后面不再描述），所有二级索引加写锁
-
如果普通索引树有间隙锁，流程待确认
PS：change buffer里应该有trx_id，配合mvcc
Update
通过主键更新
- 聚簇索引数据页读取到内存并加写锁
- 再读取唯一索引树数据页（猜测：如果要更新唯一索引值才会读）读取到内存，对聚簇索引加行锁（这里不需要对非聚簇索引加锁，因为扫描不到，根据加锁规则：只对扫描到的数据页加锁）
- 要更新的字段里，非聚簇索引字段要更改为的值是否有间隙锁（非聚簇索引应该不需要校验行锁了，因为行锁肯定会加在聚簇索引上，原本值不需要校验锁，因为只会有行锁，只校验聚簇索引即可），校验失败则进入锁等待。
- 更新聚簇索引树数据页，更新唯一索引树数据页（猜测：如果要更新才会有这一步），普通索引数据页不做更新直接写入change buffer。对所有被更新的索引字段加写锁
通过非聚簇非唯一索引进行更新（不更新主键）
- 判断要更新的字段里，非聚簇字段索引树要更改为的值是否有间隙锁
- 判断聚簇索引是否有行锁
PS：不太清楚这个判断是否有行锁的流程，可以直接从二级索引上判断吗？判断是否加锁拿主键id来判断还是二级索引值或物理位置判断？需要读出来二级索引数据页吗？ - 读取聚簇索引数据页，对聚簇索引数据行加写锁；读出查询条件的非聚簇索引数据页，对查询条件的非聚簇索引字段筛选值加间隙锁和写锁。
- 更新聚簇索引树数据页，读出并更新唯一索引树数据页（猜测：如果要更新才会有这一步），普通索引树不做更新直接写入change buffer，对所有被更新的索引字段加写锁
通过非聚簇唯一索引进行更新（不更新主键）
和非唯一索引不同的是对查询条件的非聚簇索引字段筛选值操作时，只判断和加行锁不加间隙锁（根据加锁规则，唯一索引退化为行锁）。
delete
通过主键删除
- 聚簇索引数据页读取到内存，对聚簇索引加写锁，所有二级索引加写锁。（delete只需要判断行锁不需要间隙锁）
- 更新聚簇索引树数据页（标记删除）
通过非唯一索引进行删除
- 判断筛选条件的非聚簇索引字段是否有写锁
- 聚簇索引数据页读取到内存，对聚簇索引加写锁，读取筛选条件的非聚簇索引数据页到内存，对其筛选值加next-key lock
- 更新聚簇索引树数据页（标记删除），普通索引树不做更新直接写入change buffer
通过唯一索引进行删除
- 判断筛选条件的非聚簇索引字段是否有写锁
- 聚簇索引数据页读取到内存，对聚簇索引加写锁，读取筛选条件的非聚簇索引数据页到内存，对筛选值加写锁
- 更新聚簇索引树数据页（标记删除），普通索引树不做更新直接写入change buffer
