版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/t1g2q3/article/details/84938485
- Innodb将通过主键聚集数据，如果没有定义主键，Innodb会选择第一个非空的唯一索引代替，如果没有非空唯一索引，Innodb会隐式定义一个6字节的rowid主键来作为聚集索引。
- 索引的底层原理（Page164）
- B+树是为磁盘或其他直接存取辅助设备而设计的一种平衡查找树，在B+树中，所有记录节点都是按键值的大小顺序存放在同一层的叶节点中，各叶节点指针进行连接。
- B+树索引可以分为聚集索引和辅助索引，他们不同点是，聚集索引的行数据和主键B+树存储在一起，辅助索引只存储辅助键和主键。
- 聚集索引
- 聚集索引是按每张表的主键构造的一颗B+树，并且叶节点中存放着整张表的行记录数据，因此也让聚集索引的节点成为数据页，这个特性决定了索引组织表中数据也是索引的一部分。由于实际的数据页只能按照一颗B+树进行排序，所以每张表只能拥有一个聚集索引。查询优化器非常倾向于采用聚集索引，因为其直接存储行数据，所以主键的排序查询和范围查找速度非常快。
- 不是物理上的连续，而是逻辑上的，不过在刚开始时数据是顺序插入的所以是物理上的连续，随着数据增删，物理上不再连续。
- 辅助索引
- 辅助索引页级别不包含行的全部数据。叶节点除了包含键值以外，每个叶级别中的索引行中还包含了一个书签，该书签用来告诉InnoDB哪里可以找到与索引相对应的行数据。其中存的就是聚集索引的键。
- 辅助索引的存在并不影响数据在聚集索引的结构组织。InnoDB会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键，然后通过主键索引找到一个完整的行记录。当然如果只是需要辅助索引的值和主键索引的值，那么只需要查找辅助索引就可以查询出索要的数据，就不用再去查主键索引了。
- 聚集索引
- 多版本控制和事物（MVCC）
- 一致性的非锁定行读（consistent nonlocking read）是指InnoDB存储引擎通过行多版本控制（multi versioning）的方式来读取当前执行时间数据库中行的数据。如果读取的行正在进行DELETE、UPDATE操作，这时读取操作不会因此而会等待行上锁的释放，相反，InnoDB存储引擎会去读取行的一个快照数据。
- 之所以称之为非锁定读，因为不需要等待访问的行上锁的释放。快照数据是指该行之前版本的数据，该实现是通过Undo段来实现。而Undo用来在事物中回滚数据，因此快照本身是没有额外开销的。此外，读取快照数据是不需要上锁的，因为没有必要对历史的数据进行修改。
- 非锁定读的机制大大提高了数据读取的并发性，在InnoDB存储引擎默认的设置，即读取不会占用和等待表上的锁。但是在不同事物隔离级别下，读取的方式不同，并不是每个事物隔离级别下读取的都是一致性读。同样，即使都是使用一致性读，但是对于快照的定义也不相同。
- 快照数据起始就是当前行数据之前的历史版本，可能有多个版本。一个行可能有不止一个快照数据，称这种技术为行多版本技术。由此带来的并发控制，称之为多版本并发控制（Multi Version Concurrency Control，MVCC）。
- 在Read Committed和Repeat Read下，InnoDB存储引擎使用非锁定的一致性读。然而，对于快照数据的定义却不相同。在Read Committed事物隔离级别下，对于快照数据，非一致性读总是读取被锁定行的最新一份快照数据。在Repeatable隔离级别下和Repeatable Read事物隔离级别下，对于快照数据，非一致性读总是读取事物开始时的行数据版本。
- 锁带来的3种问题
- a. 丢失更新
- 将事物变成串行操作。
- b. 脏读
- 脏读发生的条件是需要事物的隔离级别为Read Uncommitted，而目前绝大部分数据库都至少设置成Read Committed。InnoDB存储引擎默认的事物隔离级别为Read Reapeatable，Oracle数据库的默认隔离级别是Read Committed。
- c. 不可重复读
- InnoDB存储引擎中，通过使用Next-Key Lock算法来避免不可重复读的问题。在Next-Key Lock算法下，对于索引的扫描，不仅仅是锁住扫描到的索引，而且还锁住这些索引覆盖的范围（gap）。因此对于这个范围内的插入都是不允许的。这样就避免了另外的事物在这个范围内插入数据导致不可重复读的问题。因此，InnoDB存储引擎的默认事物隔离级别是Read Repeatable，采用Next-Key Lock算法，就避免了不可重复读的现象。
- 事物
- 原子性：整个数据库事物是不可分割的工作单位，只有使事物中所有的数据库操作执行都成功，才算整个事物成功。如果事物中任何一个SQL语句执行失败，那么已经执行成功的SQL语句也必须撤销，数据库状态应该退回到执行事物前的状态。
- 隔离性：一个事物的影响在该事物提交前对其他事物都不可见——通过锁来实现。
- 一致性：事物将数据库从一种状态转变为下一种一致的状态。在事物开始之前和事物结束以后，数据库的完整性约束没有被破坏。
- 持久性：事物一旦提交，其结果就是永久的。即使发生宕机等故障，数据库也能将数据恢复。
- 事物的实现
- redo
- InnoDB存储引擎中，事物日志通过重做（redo）日志文件和InnoDB存储引擎的日志缓冲（InnoDB Log Buffer）来实现。
- InnoDB存储引擎通过预写日志的方式来保证事物的完整性。磁盘上存储的数据页和内存缓冲池中的页是不同步的，对于内存缓冲池中页的修改，先是写入重做日志文件，然后再写入磁盘，因此是一种异步的方式。
- undo
- 重做日志记录了事物的行为，可以很好地通过其进行“重做”。但是事物有时还需要撤销，这时就需要undo。对数据库进行修改时，数据库不但会产生redo，而且还会产生一定量的undo。即使执行的事物或语句由于某种原因失败了，或者用一条ROLLBACK语句请求回滚，就可以利用这些undo信息将数据回滚到修改之前的样子。
- 分布式事物
- InnoDB存储引擎支持XA事物。分布式事物指的是允许多个独立的事物资源参与到一个全局的事物中。事物资源通常是关系型数据库系统。全局事物要求在其中所有参与的事物要么都提交，要么都回滚。
- 使用分布式事物时，InnoDB存储引擎的事物隔离级别必须是SERIALIABLE。