MySQL；InnoDB；索引

在 MySQL 中，索引是在存储引擎层实现的，所以并没有统一的索引标准，即不同存储引擎的索引的工作方式并不一样。而即使多个存储引擎支持同一种类型的索引，其底层的实现也可能不同；

存储引擎采用B+树，每一行在磁盘中存储为一个数据块；

每一个索引在 InnoDB 里面对应一棵 B+ 树；

主键索引的叶子节点存的是整行数据；

非主键索引的叶子节点内容是主键的值；

基于非主键索引的查询需要多扫描一棵索引树（回表）。因此，我们在应用中应该尽量使用主键查询。对于某些高频查询，建立联合索引也可以避免回表，但索引的维护是需要代价的，因此需要权衡；

有业务逻辑的字段做主键，则往往不容易保证有序插入，这样写数据成本相对较高；

显然，主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小，所以，从性能和存储空间方面考量，自增主键往往是更合理的选择；

由于覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段；

 DML（INSERT | UPDATE | DELETE）

DDL（CREATE | DORP | ALTER|）

事务隔离级别：

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。这里需要注意的是，“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。

数据库涉及到全局锁、表锁和行锁，一些数据库引擎如InnoDB通过relog等方式可以达到全局锁的目的，就可以不适用全局锁。这个时候事务和线程很像，所以他也会出现死锁的情况。

在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。

在处理锁的问题时，为了避免阻塞，可以设置超时时长；

第一种启动方式，一致性视图是在第执行第一个快照读语句时创建的；
第二种启动方式，一致性视图是在执行 start transaction with consistent snapshot 时创建的。