日志系统：
redo日志
- 将对内存中数据页的修改记录下来，并适时的通过日志更新到磁盘中，减少对磁盘的访问次数
- 采用循环写的方式
- 写指针向后移动将日志追加到文件中
- checkpoint向后移动，将前面的记录的数据写入到磁盘中
- checkpoint与写指针之间的日志是未使用的日志，checkpoint之前的日志被使用过可以被覆盖掉，写指针之后的空间时空闲的都可以使用。
- 采用两段式提交：
若是一段式提交：
- 若先提交redolog ，此时宕机，数据恢复时主库可以恢复，备份库由于binlog中没有日志就不会记录这份数据，主备不一致。
- 若先提交binlog，此时宕机，由于没有relog则主库恢复时不会存在该记录，但备份库可以从binlog中加载到该记录，主备不一致
总结：主备不一致
两段式提交： - A时刻宕机：数据恢复时，redolog处于prepare阶段不会恢复这份数据，没有binlog备份库也没有这份数据。主备一致
- B时刻宕机：数据恢复时，redolog处于prepare阶段，检查binlog是否记录，若有则将redolog改为commit状态，直接恢复即可；若没有，则忽略redolog即可。主备一致。
binlog:
逻辑日志，做数据备份
事务隔离：
- 每一个记录会有一个回滚指针指向undo日志
- 同一条记录的undo日志会连成链表
- 沿着这条链表顺序执行undo日志可以实现访问记录的历史版本
- 当undo所对应的记录版本不会被当前的任何一个事务访问到则删除这条undo日志
- 因此不要使用长事务，这会导致undo日志一直无法删除。
索引
hash索引：只适用等值查询
主键为什么要自增：
- innodb采用的是基于B+树实现的聚簇索引
- 在插入数据时，需要维护索引以保证数据的有序性
- 乱序的插入会导致大量的页分裂
- 聚簇索引的数据也放到叶子节点上，页分裂会导致大量的数据移动，十分耗费性能
为什么使用B+树而不用二叉树
- 索引存储在磁盘中，对索引树节点的访问次数等于对磁盘的访问次数
- 二叉树的深度深，会造成更多的磁盘IIO
- B+树的阶数大，深度小，对磁盘访问次数小
- Innodb中一个节点大约有1200个子节点，三层的树可以存储17亿条数据，而只需要进行3次磁盘IO就可以完成查询
索引覆盖：
建立联合索引，索引中的字段值包含要查询的字段，可以通过索引直接查询到数据而不需要回表
索引下推：
利用索引中的字段，在回表之前对数据进行筛选，排除掉一部分数据后再进行回表，减少回表次数
锁
全局锁：
- mysql提供了对整个数据库实例加读锁的机制，通常用于对数据库进行备份
- 加锁后，数据库处于只读状态，这样线上的业务会停摆
若使用Innodb引擎，可以使用可重复读的隔离级别对数据库进行快照读
表级锁：
表锁：可以对整张表加读锁或者写锁
元数据锁：用来锁定表的结构
对表加字段时，可以加元数据写锁，此时表不能读也不能写
