InnoDB

B+树索引将索引列的值按大小排序后存储，因此适合范围查找和排序操作；而哈希索引则通过哈希函数计算索引列的值，得到一个桶的编号，然后将桶内记录保存在链表或树结构中。因此，哈希索引适合等值查询，但不适合范围查询和排序操作。

往期在文章《介绍Innodb的锁机制》中提到过关于记录锁，但是没有详细展开描述，本片文章简单聊一聊。

根据不同的事务隔离级别，在InnoDB中，获取Read View的时机有所不同。在可重复读隔离级别下，每次查询都会重新获取一次Read View，而在读已提交隔离级别下，只有在事务的第一次查询时获取一次Read View。

在Repeatable Read隔离级别下，通过MVCC机制解决了快照读导致的幻读问题。在该隔离级别下，进行快照读时仅在第一次进行数据查询，随后直接读取快照，因此不会发生幻读。

不可重复读指一个事务读取同一行数据两次，但在两次读取之间另一个事务修改了该行数据，导致两次读取结果不同。InnoDB通过MVCC来解决不可重复读的问题。

在创建数据库时，选择合适的存储引擎是至关重要的。InnoDB因其支持事务处理、行级锁定和外键约束而被广泛推荐。它提供了高性能和数据完整性的保证，适合需要处理大量短期事务的应用。

InnoDB 的全文检索在一些简单的搜索场景下还是比较实用的，可以替代 like+%，并且不需要额外依赖其他服务。

为了提升分配 undo 段的效率，事务提交过程中，InnoDB 会缓存一些 undo 段。只要同时满足两个条件，insert undo 段或 update undo 段就能被缓存。

当我们进行数据插入的时候，对于唯一索引，实际上大概会经历数据查找，唯一性检查、数据插入三个阶段。

产生幻读的原因是，行锁只能锁住行，但是新插入记录这个动作，要更新的是记录之间的“间隙”。因此，为了解决幻读问题，InnoDB 只好引入新的锁，也就是间隙锁 (Gap Lock)，间隙锁是在可重复读隔离级别下才会生效的。

根据上面三种不同情况下的计算，可以看出，InnoDB三层B+树情况下的数据存储量范围为 一百二十多万条 到 将近5亿条，这个跨度还是非常大的，同时我们也计算了一张博客信息表，可以存储约 一千万条 数据。

不管是页分裂还是页合并，InnoDB都会在索引树上加写锁（x-latch）。在操作频繁的系统中这会是在隐患，可能会导致索引的锁竞争（index latch contention）。如果表中没有合并和分裂操作（也就是写操作），称之为“乐观（optimistic）”更新，只需要使用读锁（S）。带有合并或者分裂的操作称之为“悲观（pessimistic）”更新，使用写锁（X）。​

对于 first-committer-wins 的定义, 在si 模式下, 如果在Start-Timestamp -> Commit-Timestamp 这之间如果有其他的trx2 修改了当前trx1 修改过的内容, 并且在trx1 提交的时候, trx2 已经提交了. 那么trx1 就会abort, 这个叫first-committer-wins。

对于count(*)来说，InnoDB只好把数据一行行读出来，对可见的行进行统计。因此，InnoDB不能像MyISAM引擎一样在磁盘保存数据行树。

InnoDB是一个将数据存储到磁盘上的存储引擎，所以就算我们关闭、重启服务器，数据还是存在的。而在真正处理数据的时候是在内存中进行的，所以需要把磁盘中的内容加载到内存中。