1.InnoDB

1.1 innodb存储引擎的mysql表提供了事务，回滚以及系统崩溃修复能力和多版本迸发控制的事务的安全
1.2 innodb支持自增长列（auto_increment）,自增长列的值不能为空，如果在使用的时候为空的话怎会进行自动存现有的值开始增值，如果有但是比现在的还大，则就保存这个值
1.3 innodb存储引擎支持外键（foreign key） ,外键所在的表称为子表而所依赖的表称为父表
1.4 innodb存储引擎最重要的是支持事务，以及事务相关联功能
1.5 innodb采用mvcc支持高并发，并且实现了4个标准的隔离级别，默认可重复读，并且通过间隙锁策略放置幻读的出现（间隙锁使得innodb不仅仅锁定查询涉及到的行，还会对索引中的间隙进行锁定，以防止幻影行的插入）
1.6 innodb存储引擎索引使用的是B+Tree

2.MyISAM引擎

2.1 不支持事务，不支持行级锁，只支持并发插入的表锁，主要用于高负载的select
2.2 支持三种不同的存储结构：静态型、动态型、压缩型。

2.2.1静态型：就是定义的表列的大小是固定（即不含有：xblob、xtext、varchar等长度可变的数据类型），这样mysql就会自动使用静态myisam格式。使用静态格式的表的性能比较高，因为在维护和访问的时候以预定格式存储数据时需要的开销很低。但是这高性能是有空间换来的，因为在定义的时候是固定的，所以不管列中的值有多大，都会以最大值为准，占据了整个空间。
2.2.2 动态型：如果列（即使只有一列）定义为动态的（xblob, xtext, varchar等数据类型），这时myisam就自动使用动态型，虽然动态型的表占用了比静态型表较少的空间，但带来了性能的降低，因为如果某个字段的内容发生改变则其位置很可能需要移动，这样就会导致碎片的产生。随着数据变化的怎多，碎片就会增加，数据访问性能就会相应的降低。
2.2.3 压缩型：如果在这个数据库中创建的是在整个生命周期内只读的表，则这种情况就是用myisam的压缩型表来减少空间的占用。

3.MEMORY引擎

3.1MEMORY存储引擎提供“内存”表， 也不支持事务、 外键
3.2磁盘文件只存储表结构，数据都存储在内存中。
3.3存储引擎默认使用哈希（HASH）索引，其速度比使用B-+Tree型要快，如果读者希望使用B树型，则在创建的时候可以引用。
3.4文件数据都存储在内存中，如果mysqld进程发生异常，重启或关闭机器这些数据都会消失。所以memory存储引擎中的表的生命周期很短，一般只使用一次

4.BlackHole存储引擎

4.1支持事务，而且支持mvcc的行级锁，主要用于日志记录或同步归档，这个存储引擎除非有特别目的，否则不适合使用！

5.存储引擎选择

5.1是否需要事务支持

5.2是否为高并发， InnoDB实现了行锁， 这方面的表现大大优于MyISAM

5.3索引， 不同存储引擎的索引实现不尽相同

5.4是否需要外键

5.5高效缓冲数据， InnoDB缓冲数据而MyISAM只缓冲了索引

5.6备份， 是否需要支持热备份

6.概念讲解

6.1 事务ACID 特性

原子性，一致性，隔离性，持久性

6.2 事务的隔离级别

read uncommitted(未提交读)

在该级别中，事务中的修改，及时没有提交，对其他事务也是可见的。事务可以读取未提交的数据，也成为 dirty read

read committed(提交读)

一个事务开始时，只能看见已提交的事务所做出的修改（一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的，因此也叫做不可重复读，因为两次执行同样的查询，可能得到的不同的结果）

repeatable read(可重复读)

解决 dirty read的问题，该级别保证了在同一个事务中多次读取同样记录的结果是一致的，但无法解决换读的问题，所谓幻读指当前某个事务在独立某个范围内的记录时，另一个事务又在该范围内插入了新记录。innodb通过 引入mvcc解决了幻读的问题

seriablizable(可串行化)

最高的隔离级别，强制事务串行执行，避免幻读问题。在读取的每一行上加锁，可能导致大量的超时和锁竞争的问题，实际中很少用。

6.2 mvcc

多版本并发控制

mvcc是行锁的变种，但是他在很多情况下避免了加锁操作，因此开销更低。大多实现了非阻塞的读操作，写操作也只锁定必要的行。mvcc的实现是通过保存数据在某个时间点的快照来实现的，也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的，根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的

innodb的mvcc是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行创建的时间，一个保存行的过期时间/删除时间。当然存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号就会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。

image.png

保存的两个额外的系统版本号，使大多数读操作都可以不用加锁，该设计使得读数据操作很简单，性能很好，不足之处就是需要额外的空间，需要做更多的检查工作，以及一些额外的维护工作。

6.3 数据库锁

锁对主要作用是管理共享资源的并发访问,用于实现事务的隔离性

锁类型

读锁（共享锁）
写锁（独占锁）

死锁

事务间的循环依赖导致死锁发生，innodb通过检测循环依赖来检测死锁，并且将最少行级排他锁的事务进行回滚

MySQL锁的粒度

表级锁（开销小，并发性低），通常在服务器层实现
行级锁（开销大，并发性高），只会在存储引擎层面进行实现

隐式和显式锁定

InnoDB采用的式两阶段锁定协议。在事务执行过程中，随时都可以执行锁定，锁只有在执行 commit / rollback 时才会释放，并且所有的锁是同一时刻释放