关于InnoDB

InnoDB是MySQL的默认事务型引擎，它被设计用来处理大量的短期(short-lived)事务。MySQL4.1以后的版本中，InnoDB可以将每个表的数据和索引存放在单独的文件中。这样在复制备份崩溃恢复等操作中有明显优势。可以通过在my.cnf中增加innodb_file_per_table来开启或关闭独立的表空间。

Innodb 使用MVCC来支持高并发，并实现了四个标准的隔离级别，默认级别为repeatable read，并且通过间隙锁来防止幻读。

InnoDB是基于聚簇索引建立的，聚簇索引对主键查询有很高的性能。不过它的二级索引(secondary index，非主键索引)中必须包含主键列，所以如果主键列很大的话，其他的所有索引都会很大。因此表上的索引较多的话，主键应当尽可能的小。


InnoDB做了一些优化，从磁盘读取数据时采用可预测预读，能够自动在内存中创建hash索引以加速读操作的自适应哈希索引，以及能够加速插入操作的插入缓冲区

InnoDB的存储格式是平台独立的，可以将数据和索引文件从Intel平台复制到Sun SPARC平台或其他平台。

InnoDB通过一些机制和工具支持真正的热备份，MySQL的其他存储引擎不支持热备份。

其他

1.隐式锁显式锁
InnoDB在开启事务时，获取隐式锁，在事务提交或者回滚时释放锁，InnoDB根据隔离级别在需要的时候自动加锁。
但InnoDB也支持显式锁：
SELECT ... FOR UPDATE
SELECT ... LOCK IN SHARE MODE
这是在服务器层实现的，和存储引擎无关。本书建议除了禁用了AUTOCOMMIT，可以使用LOCK_TABLES之外，其他任何时候都不要显示地执行LOCK TABLES，不管使用的是什么存储引擎。

2.多版本并发控制（Multiversion Concurrency Controll MVCC）
MVCC并不是MySql独有的，Oracle，PostgreSQL等都在使用。
MVCC并没有简单地使用行锁，而是使用“行级别锁”（row-level locking）。
MVCC的基本原理是：
MVCC的实现，通过保存数据在某个时间点的快照来实现的。这意味着一个事务无论运行多长时间，在同一个事务里能够看到数据一致的视图。根据事务开始的时间不同，同时也意味着在同一个时刻不同事务看到的相同表里的数据可能是不同的。

MVCC只在REPEATABLE READ和READ COMMITED两个隔离级别下工作，其它两个隔离级别和MVCC不兼容。
MVCC的基本特征：
• 每行数据都存在一个版本，每次数据更新时都更新该版本。
• 修改时Copy出当前版本随意修改，各个事务之间无干扰。
• 保存时比较版本号，如果成功（commit），则覆盖原记录；失败则放弃copy（rollback）
InnoDB存储引擎MVCC的实现策略：
• 在 每一行数据中额外保存两个隐藏的列：当前行创建时的版本号和删除时的版本号（可能为空）。这里的版本号并不是实际的时间值，而是系统版本号。每开始 个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询每行记录的版本号进行比较。
• 每个事务又有自己的版本号，这样事务内执行CRUD操作时，就通过版本号的比较来达到数据版本控制的目的。具体做法见下面的示意图。

3. 自适应哈希索引
哈希索引是一种非常快的等值查找方法（注意：必须是等值，哈希索引对非等值查找方法无能为力），它查找的时间复杂度为常量，InnoDB采用自适用哈希索引 技术，它会实时监控表上索引的使用情况，如果认为建立哈希索引可以提高查询效率，则自动在内存中的“自适应哈希索引缓冲区”建立哈希索引。
之所以该技术称为“自适应”是因为完全由InnoDB自己决定，不需要DBA人为干预。它是通过缓冲池中的B+树构造而来，且不需要对整个表建立哈希索引，因此它的数据非常快。

InnoDB官方文档显示，启用自适应哈希索引后，读和写性能可以提高2倍，对于辅助索引的连接操作，性能可以提高5被，因此默认情况下为开启，我们可以通过参数innodb_adaptive_hash_index来禁用此特性。