Mysql总结，可用于面试

1、并发控制

为啥要进行并发控制？

并发的任务对同一个临界资源进行操作，如果不采取措施，可能导致不一致，故必须进行并发控制（Concurrency Control）。

技术上，通过并发控制保证数据一致性的常见手段有：

锁（Locking）

数据多版本（Multi Versioning）

2、锁

如何使用普通锁保证一致性？

普通锁，被使用最多：

(1)操作数据前，锁住，实施互斥，不允许其他的并发任务操作；

(2)操作完成后，释放锁，让其他任务执行；

如此这般，来保证一致性。

普通锁存在什么问题？

简单的锁住太过粗暴，连“读任务”也无法并行，任务执行过程本质上是串行的。

于是出现了共享锁与排他锁：

共享锁（Share Locks，记为S锁），读取数据时加S锁

排他锁（eXclusive Locks，记为X锁），修改数据时加X锁

共享锁与排他锁的玩法是：

共享锁之间不互斥，简记为：读读可以并行

排他锁与任何锁互斥，简记为：写读，写写不可以并行

可以看到，一旦写数据的任务没有完成，数据是不能被其他任务读取的，这对并发度有较大的影响。

即：对应到数据库，可以理解为，写事务没有提交，读相关数据的select也会被阻塞。

有没有可能，进一步提高并发呢？

即使写任务没有完成，其他读任务也可能并发，这就引出了数据多版本。

3、数据多版本

数据多版本是一种能够进一步提高并发的方法，它的核心原理是：

（1）写任务发生时，将数据克隆一份，以版本号区分；

（2）写任务操作新克隆的数据，直至提交；

（3）并发读任务可以继续读取旧版本的数据，不至于阻塞；

如上图：

1. 最开始数据的版本是V0；

2. T1时刻发起了一个写任务，这是把数据clone了一份，进行修改，版本变为V1，但任务还未完成；

3. T2时刻并发了一个读任务，依然可以读V0版本的数据；

4. T3时刻又并发了一个读任务，依然不会阻塞；

可以看到，数据多版本，通过“读取旧版本数据”能够极大提高任务的并发度。

提高并发的演进思路，就在如此：

普通锁，本质是串行执行

读写锁，可以实现读读并发

数据多版本，可以实现读写并发

4、redo, undo,回滚段

在进一步介绍InnoDB如何使用“读取旧版本数据”极大提高任务的并发度之前，有必要先介绍下redo日志，undo日志，回滚段（rollback segment）。

4.1为什么要有redo日志？

数据库事务提交后，必须将更新后的数据刷到磁盘上，以保证ACID特性。磁盘随机写性能较低，如果每次都刷盘，会极大影响数据库的吞吐量。

优化方式是，将修改行为先写到redo日志里（此时变成了顺序写），再定期将数据刷到磁盘上，这样能极大提高性能。这里的架构设计方法是，随机写优化为顺序写。

假如某一时刻，数据库崩溃，还没来得及刷盘的数据，在数据库重启后，会重做redo日志里的内容，以保证已提交事务对数据产生的影响都刷到磁盘上。

一句话，redo日志用于保障，已提交事务的ACID特性。

4.2为什么要有undo日志？

数据库事务未提交时，会将事务修改数据的镜像（即修改前的旧版本）存放到undo日志里，当事务回滚时，或者数据库奔溃时，可以利用undo日志，即旧版本数据，撤销未提交事务对数据库产生的影响。

更细节的，

对于insert操作，undo日志记录新数据的PK(ROW_ID)，回滚时直接删除；

对于delete/update操作，undo日志记录旧数据row，回滚时直接恢复；

他们分别存放在不同的buffer里。

一句话，undo日志用于保障，未提交事务不会对数据库的ACID特性产生影响。

4.3什么是回滚段？

存储undo日志的地方，是回滚段。

undo日志和回滚段和InnoDB的MVCC密切相关，这里举个例子展开说明一下。

栗子：

t(id PK, name);

数据为：

1, shenjian

2, zhangsan

3, lisi

此时没有事务未提交，故回滚段是空的。

接着启动了一个事务：

start trx;

delete (1, shenjian);

update set(3, lisi) to (3, xxx);

insert (4, wangwu);

并且事务处于未提交的状态。

可以看到：

(1)被删除前的(1, shenjian)作为旧版本数据，进入了回滚段；

(2)被修改前的(3, lisi)作为旧版本数据，进入了回滚段；

(3)被插入的数据，PK(4)进入了回滚段；

接下来，假如事务rollback，此时可以通过回滚段里的undo日志回滚。此外：假设事务提交，回滚段里的undo日志可以删除。

可以看到：

(1)被删除的旧数据恢复了；

(2)被修改的旧数据也恢复了；

(3)被插入的数据，删除了；

事务回滚成功，一切如故。

5、InnoDB是基于多版本并发控制的存储引擎

InnoDB是高并发互联网场景最为推荐的存储引擎，根本原因，就是其多版本并发控制（Multi Version Concurrency Control, MVCC）。行锁，并发，事务回滚等多种特性都和MVCC相关。

MVCC就是通过“读取旧版本数据”来降低并发事务的锁冲突，提高任务的并发度。

通过上文undo日志和回滚段的描述，可知：

(1)旧版本数据存储在回滚段里；

(2)对MySQL和InnoDB原有架构体系冲击不大；

InnoDB的内核，会对所有row数据增加三个内部属性：

(1)DB_TRX_ID，6字节，记录每一行最近一次修改它的事务ID；

(2)DB_ROLL_PTR，7字节，记录指向回滚段undo日志的指针；

(3)DB_ROW_ID，6字节，单调递增的行ID；

InnoDB为何能够做到这么高的并发？

回滚段里的数据，其实是历史数据的快照（snapshot），这些数据是不会被修改，select可以肆无忌惮的并发读取他们。

快照读（Snapshot Read），这种一致性不加锁的读（Consistent Nonlocking Read），就是InnoDB并发如此之高的核心原因之一。

这里的一致性是指，事务读取到的数据，要么是事务开始前就已经存在的数据（当然，是其他已提交事务产生的），要么是事务自身插入或者修改的数据。

6、总结

(1)常见并发控制保证数据一致性的方法有锁，数据多版本；

(2)普通锁串行，读写锁读读并行，数据多版本读写并行；

(3)redo日志保证已提交事务的ACID特性，设计思路是，通过顺序写替代随机写，提高并发；

(4)undo日志用来回滚未提交的事务，它存储在回滚段里；

(5)InnoDB是基于MVCC的存储引擎，它利用了存储在回滚段里的undo日志，即数据的旧版本，提高并发；

(6)InnoDB之所以并发高，快照读不加锁；

(7)InnoDB所有普通select都是快照读；

1、事务隔离级别

隔离性是指，多个用户的并发事务访问同一个数据库时，一个用户的事务不应该被其他用户的事务干扰，多个并发事务之间要相互隔离。

读未提交:事务还没提交时，它做的变更就能被别的事务看到

读已提交:事务提交之后，它做的变更才会被其他事务看到

可重复读:事务执行过程中看到的数据，总是跟事务启动时看到的数据一致

串行化:退化为基于“读写锁”控制并发。读写冲突，并发度急剧下降

如果控制不好隔离级别，就有可能产生脏读、不可重复读或者幻读等读现象。

脏读：读到了未提交事务操作的记录；

不可重复读：同一个事务里相同的查询语句，前后两次查询结果不一致:第二次查询到其它事务更新/删除的数据 ，即为不可重复读，通过加记录锁解决；

幻读：第二次查询到其它事务新增的数据，即出现了幻读，通过加Next-Key锁解决

不同事务的隔离级别，实际上是一致性与并发性的一个权衡与折衷。

InnoDB的四种事务的隔离级别，分别是怎么实现的？

InnoDB使用不同的锁策略(Locking Strategy)来实现不同的隔离级别。

2、InnoDB隔离级别的实现

2.1读未提交(Read Uncommitted)

这种事务隔离级别下，select语句不加锁。

此时，可能读取到不一致的数据，即“读脏”。这是并发最高，一致性最差的隔离级别。

2.2****串行化(Serializable)

这种事务的隔离级别下，所有select语句都会被隐式的转化为select ... in share mode.

这可能导致，如果有未提交的事务正在修改某些行，所有读取这些行的select都会被阻塞住。

这是一致性最好的，但并发性最差的隔离级别。

在互联网大数据量，高并发量的场景下，几乎不会使用上述两种隔离级别。

2.3****可重复读(Repeated Read, RR)

这是InnoDB默认的隔离级别，在RR下：

(1)普通的select使用快照读(snapshot read)，这是一种不加锁的一致性读(Consistent Nonlocking Read)，底层使用MVCC来实现；

(2)加锁的select(select ... in share mode / select ... for update), update, delete等语句，它们的锁，依赖于它们是否在唯一索引(unique index)上使用了唯一的查询条件(unique search condition)，或者范围查询条件(range-type search condition)：

在唯一索引上使用唯一的查询条件，会使用**记录锁(record lock)，而不会封锁记录之间的间隔，即不会使用间隙锁(gap lock)与临键锁(next-key lock)**

范围查询条件，会使用间隙锁与临键锁，锁住索引记录之间的范围，避免范围间插入记录，以避免产生幻影行记录，以及避免不可重复的读

2.4****读提交(Read Committed, RC)

这是互联网最常用的隔离级别，在RC下：

(1)普通读是快照读；

(2)加锁的select, update, delete等语句，除了在外键约束检查(foreign-key constraint checking)以及重复键检查(duplicate-key checking)时会封锁区间，其他时刻都只使用记录锁；

此时，其他事务的插入依然可以执行，就可能导致，读取到幻影记录。

3总结

并发事务之间相互干扰，可能导致事务出现读脏，不可重复度，幻读等问题

InnoDB实现了SQL92标准中的四种隔离级别

(1)读未提交：select不加锁，可能出现读脏；

(2)**读提交(RC)**：普通select快照读，锁select /update /delete 会使用记录锁，可能出现不可重复读；

(3)**可重复读(RR)**：普通select快照读，锁select /update /delete 根据查询条件情况，会选择记录锁，或者间隙锁/临键锁，以防止读取到幻影记录；

(4)串行化：select隐式转化为select ... in share mode，会被update与delete互斥；

InnoDB默认的隔离级别是RR，用得最多的隔离级别是RC

1、快照读(Snapshot Read)

MySQL数据库，InnoDB存储引擎，为了提高并发，使用MVCC机制，在并发事务时，通过读取数据行的历史数据版本，不加锁，来提高并发的一种不加锁一致性读(Consistent Nonlocking Read)。

2、读提交(Read Committed)

数据库领域，事务隔离级别的一种，简称RC

它解决“读脏”问题，保证读取到的数据行都是已提交事务写入的

它可能存在“读幻影行”问题，同一个事务里，连续相同的read可能读到不同的结果集

3、可重复读(Repeated Read)

数据库领域，事务隔离级别的一种，简称RR

它不但解决“读脏”问题，还解决了“读幻影行”问题，同一个事务里，连续相同的read读到相同的结果集

4、快照读在RC和RR下的区别

在读提交(RC)，可重复读(RR)两个不同的事务的隔离级别下，快照读有什么不同呢？

事务总能够读取到，自己写入(update /insert /delete)的行记录

RC下，快照读总是能读到最新的行数据快照，当然，必须是已提交事务写入的

RR下，某个事务首次read记录的时间为T，未来不会读取到T时间之后已提交事务写入的记录，以保证连续相同的read读到相同的结果集

可以看到：

(1)和并发事务的开始时间没关系，和事务首次read的时间有关；

(2)由于不加锁，和互斥关系也不大；

InnoDB的七种锁

1、共享锁/排他锁

(1)事务拿到某一行记录的共享S锁，才可以读取这一行；

(2)事务拿到某一行记录的排它X锁，才可以修改或者删除这一行；

其兼容互斥表如下：

S

X

S

兼容

互斥

X

互斥

互斥

即：

(1)多个事务可以拿到一把S锁，读读可以并行；

(2)而只有一个事务可以拿到X锁，写写/读写必须互斥；

共享/排它锁的潜在问题是，不能充分的并行，解决思路是数据多版本。

2、意向锁

InnoDB支持多粒度锁(multiple granularity locking)，它允许行级锁与表级锁共存，实际应用中，InnoDB使用的是意向锁。

意向锁是指，未来的某个时刻，事务可能要加共享/排它锁了，先提前声明一个意向。

意向锁有这样一些特点：

(1)首先，意向锁，是一个表级别的锁(table-level locking)；

(2)意向锁分为：

意向共享锁(intention shared lock, IS)，它预示着，事务有意向对表中的某些行加共享S锁

意向排它锁(intention exclusive lock, IX)，它预示着，事务有意向对表中的某些行加排它X锁

举个例子：

select ... lock in share mode，要设置IS锁；

select ... for update，要设置IX锁；

(3)意向锁协议(intention locking protocol)并不复杂：

事务要获得某些行的S锁，必须先获得表的IS锁

事务要获得某些行的X锁，必须先获得表的IX锁

(4)由于意向锁仅仅表明意向，它其实是比较弱的锁，意向锁之间并不相互互斥，而是可以并行，其兼容互斥表如下：

IS

IX

IS

兼容

兼容

IX

兼容

兼容

(5)额，既然意向锁之间都相互兼容，那其意义在哪里呢？它会与共享锁/排它锁互斥，其兼容互斥表如下：

S

X

IS

兼容

互斥

IX

互斥

互斥

即：排它锁是很强的锁，不与其他类型的锁兼容。这也很好理解，修改和删除某一行的时候，必须获得强锁，禁止这一行上的其他并发，以保障数据的一致性。

3、自增锁

自增锁是一种特殊的表级别锁（table-level lock），专门针对事务插入AUTO_INCREMENT类型的列。最简单的情况，如果一个事务正在往表中插入记录，所有其他事务的插入必须等待，以便第一个事务插入的行，是连续的主键值。

与此同时，InnoDB提供了innodb_autoinc_lock_mode配置，可以调节与改变该锁的模式与行为。

4、插入意向锁

对已有数据行的修改与删除，必须加强互斥锁X锁，那对于数据的插入，是否还需要加这么强的锁，来实施互斥呢？插入意向锁，孕育而生。

插入意向锁，是间隙锁(Gap Locks)的一种（所以，也是实施在索引上的），它是专门针对insert操作的。

即：它是一种实施在索引上，锁定索引某个区间范围的锁。

它的玩法是：

多个事务，在同一个索引，同一个范围区间插入记录时，如果插入的位置不冲突，不会阻塞彼此。

思路总结

(1)InnoDB使用共享锁，可以提高读读并发；

(2)为了保证数据强一致，InnoDB使用强互斥锁，保证同一行记录修改与删除的串行性；

(3)InnoDB使用插入意向锁，可以提高插入并发；

5、记录锁(Record Locks)

记录锁，它封锁索引记录，例如：

select * from t where id=1 for update;

它会在id=1的索引记录上加锁，以阻止其他事务插入，更新，删除id=1的这一行。

需要说明的是：

select * from t where id=1;

则是快照读(SnapShot Read)，它并不加锁。

另外，

如果没有定义任何索引，会在聚簇索引上加锁

没有走任何索引，会在每一条聚集索引记录上加记录锁

6、间隙锁(Gap Locks)

间隙锁，它封锁索引记录中的间隔，或者第一条索引记录之前的范围，又或者最后一条索引记录之后的范围。

间隙锁的主要目的，就是为了防止其他事务在间隔中插入数据，以导致“不可重复读”。

如果把事务的隔离级别降级为读提交(Read Committed, RC)，间隙锁则会自动失效。

7、临键锁(Next-Key Locks)

临键锁，是记录锁与间隙锁的组合，它的封锁范围，既包含索引记录，又包含索引区间。

更具体的，临键锁会封锁索引记录本身，以及索引记录之前的区间。

如果一个会话占有了索引记录R的共享/排他锁，其他会话不能立刻在R之前的区间插入新的索引记录。

临键锁的主要目的，也是为了避免幻读(Phantom Read)。如果把事务的隔离级别降级为RC，临键锁则也会失效。对查询的索引含有唯一性时，Next-Key锁会降级为记录锁。

8、总结

(1)InnoDB的索引与行记录存储在一起，这一点和MyISAM不一样；

(2)InnoDB的聚集索引存储行记录，普通索引存储PK，所以普通索引要查询两次；

(3)InnoDB使用共享锁，可以提高读读并发；

(4)为了保证数据强一致，InnoDB使用强互斥锁，保证同一行记录修改与删除的串行性；

(5)InnoDB使用插入意向锁，可以提高插入并发；

(6)记录锁锁定索引记录；

(7)间隙锁锁定间隔，防止间隔中被其他事务插入；

(8)临键锁锁定索引记录+间隔，防止幻读；

各种sql用到了那些锁

1普通select

(1)在读未提交(Read Uncommitted)，读提交(Read Committed, RC)，可重复读(Repeated Read, RR)这三种事务隔离级别下，普通select使用快照读(snpashot read)，不加锁，并发非常高；

(2)在串行化(Serializable)这种事务的隔离级别下，普通select会升级为select ... in share mode;

2加锁select

加锁select主要是指：

select ... for update

select ... in share mode

(1)如果，在唯一索引(unique index)上使用唯一的查询条件(unique search condition)，会使用记录锁(record lock)，而不会封锁记录之间的间隔，即不会使用间隙锁(gap lock)与临键锁(next-key lock)；

举个栗子，假设有InnoDB表：

t(id PK, name);

表中有三条记录：

1, shenjian

2, zhangsan

3, lisi

SQL语句：

select * from t where id=1 for update;

只会封锁记录，而不会封锁区间。

(2)其他的查询条件和索引条件，InnoDB会封锁被扫描的索引范围，并使用间隙锁与临键锁，避免索引范围区间插入记录；

3update与delete

(1)和加锁select类似，如果在唯一索引上使用唯一的查询条件来update/delete，例如：

update t set name=xxx where id=1;

也只加记录锁；

(2)否则，符合查询条件的索引记录之前，都会加排他临键锁(exclusive next-key lock)，来封锁索引记录与之前的区间；

(3)尤其需要特殊说明的是，如果update的是聚集索引(clustered index)记录，则对应的普通索引(secondary index)记录也会被隐式加锁，这是由InnoDB索引的实现机制决定的：普通索引存储PK的值，检索普通索引本质上要二次扫描聚集索引。

4insert

同样是写操作，insert和update与delete不同，它会用排它锁封锁被插入的索引记录，而不会封锁记录之前的范围。

同时，会在插入区间加插入意向锁(insert intention lock)，但这个并不会真正封锁区间，也不会阻止相同区间的不同KEY插入。

死锁

1、死锁的关键在于:两个(或以上)的事务加锁的顺序不一致。

2、分析每条SQL的加锁规则和加锁顺序，然后检查多个并发SQL间是否存在以相反的顺序加锁的情况，就可以分析出各种潜在的死锁情况，也可以分析出线上死锁发生的原因

索引

索引是数据结构，数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化。最基本的查询算法当然是顺序查找（linear search），这种复杂度为O(n)的算法在数据量很大时显然是糟糕的，好在计算机科学的发展提供了很多更优秀的查找算法，例如二分查找（binary search）、二叉树查找（binary tree search）等。如果稍微分析一下会发现，每种查找算法都只能应用于特定的数据结构之上，例如二分查找要求被检索数据有序，而二叉树查找只能应用于二叉查找树上，但是数据本身的组织结构不可能完全满足各种数据结构（例如，理论上不可能同时将两列都按顺序进行组织），所以，在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

1.常见数据结构

1.1 二叉搜索树

二叉搜索树，如上图，是最为大家所熟知的一种数据结构，但是它不适合用作数据库索引，原因如下：

(1)当数据量大的时候，树的高度会比较高，数据量大的时候，查询会比较慢；

(2)每个节点只存储一个记录，可能导致一次查询有很多次磁盘IO；

1.2 B树

B树，如上图，它的特点是：

(1)不再是二叉搜索，而是m叉搜索；

(2)叶子节点，非叶子节点，都存储数据；

(3)中序遍历，可以获得所有节点；

B树适合做索引的原因：

(1)由于是m分叉的，高度能够大大降低；

(2)每个节点可以存储j个记录，如果将节点大小设置为页大小，例如4K，能够充分的利用预读的特性，极大减少磁盘IO；

1.3 B+树

B+树，如上图，仍是m叉搜索树，在B树的基础上，做了一些改进：

(1)非叶子节点不再存储数据，数据只存储在同一层的叶子节点上；也就是说B+树中根到每一个节点的路径长度一样，而B树不是这样。

(2)叶子之间，增加了链表，获取所有节点，不再需要中序遍历；

这些改进让B+树比B树有更优的特性：

(1)范围查找，定位min与max之后，中间叶子节点，就是结果集，不用中序回溯；范围查询在SQL中用得很多，这是B+树比B树最大的优势。

(2)叶子节点存储实际记录行，记录行相对比较紧密的存储，适合大数据量磁盘存储；非叶子节点存储记录的PK，用于查询加速，适合内存存储；

(3)非叶子节点，不存储实际记录，而只存储记录的KEY的话，那么在相同内存的情况下，B+树能够存储更多索引；

2. 局部性原理

局部性原理的逻辑是这样的：

(1)内存读写块，磁盘读写慢，而且慢很多；

(2)磁盘预读：磁盘读写并不是按需读取，而是按页预读，一次会读一页的数据，每次加载更多的数据，如果未来要读取的数据就在这一页中，可以避免未来的磁盘IO，提高效率；通常，一页数据是4K。

(3)局部性原理：软件设计要尽量遵循“数据读取集中”与“使用到一个数据，大概率会使用其附近的数据”，这样磁盘预读能充分提高磁盘IO；

而B树或者B+树由于是m叉的，每个节点可以存储j个记录，那么如果将节点大小设置为页大小，例如4K，能够充分的利用预读的特性，极大减少磁盘IO；

3.非聚簇索引

一种索引，该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。或者说，在索引树的叶子节点存储的仍然是索引（值在内存中的地址），指向内存中对应的数据块。

4.聚簇索引

一种索引，该索引中键值的逻辑顺序决定了表中相应行的物理顺序。 从索引树来看，就是说索引树的叶子节点存储的就是数据块。

下面，我们举例来说明一下聚集索引和非聚集索引的区别：

　　其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。

　　如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。

也就是说按拼音查询的就是聚簇索引，按偏旁部首查询的就是非聚簇索引。感觉还是挺生动的。。。

5. 总结

数据库的索引最常用B+树：

(1)很适合磁盘存储，能够充分利用局部性原理，磁盘预读；

(2)很低的树高度，能够存储大量数据；

(3)索引本身占用的内存很小；

(4)能够很好的支持单点查询，范围查询，有序性查询；

MyISAM和InnoDB的差异

1.MyISAM的索引

MyISAM的索引与行记录是分开存储的，叫做非聚集索引（UnClustered Index）。

其主键索引与普通索引没有本质差异：

有连续聚集的区域单独存储行记录

主键索引的叶子节点，存储主键，与对应行记录的指针

普通索引的叶子结点，存储索引列，与对应行记录的指针

也就是说：MyISAM的表可以没有主键。

主键索引与普通索引是两棵独立的索引B+树，通过索引列查找时，先定位到B+树的叶子节点，再通过指针定位到行记录。

举个例子，MyISAM：

t(id PK, name KEY, sex, flag);

表中有四条记录：

1, shenjian, m, A

3, zhangsan, m, A

5, lisi, m, A

9, wangwu, f, B

其B+树索引构造如上图：

行记录单独存储

id为PK，有一棵id的索引树，叶子指向行记录

name为KEY，有一棵name的索引树，叶子也指向行记录

2.InnoDB的索引

InnoDB的主键索引与行记录是存储在一起的，故叫做聚集索引（Clustered Index）：

没有单独区域存储行记录

主键索引的叶子节点，存储主键，与对应行记录（而不是指针）

也就是说：因此，InnoDB的PK查询是非常快的。

因为这个特性，InnoDB的表必须要有聚集索引：

(1)如果表定义了PK，则PK就是聚集索引；

(2)如果表没有定义PK，则第一个非空unique列是聚集索引；

(3)否则，InnoDB会创建一个隐藏的row-id作为聚集索引；

聚集索引，也只能够有一个，因为数据行在物理磁盘上只能有一份聚集存储。

InnoDB的普通索引可以有多个，它与聚集索引是不同的：

普通索引的叶子节点，存储主键（也不是指针）

对于InnoDB表，这里的启示是：

(1)不建议使用较长的列做主键，例如char(64)，因为所有的普通索引都会存储主键，会导致普通索引过于庞大；

(2)建议使用趋势递增的key做主键，由于数据行与索引一体，这样不至于插入记录时，有大量索引分裂，行记录移动；

仍是上面的例子，只是存储引擎换成InnoDB：

t(id PK, name KEY, sex, flag);

表中还是四条记录：

1, shenjian, m, A

3, zhangsan, m, A

5, lisi, m, A

9, wangwu, f, B

其B+树索引构造如上图：

id为PK，行记录和id索引树存储在一起

name为KEY，有一棵name的索引树，叶子存储id

当：

select * from t where name=‘lisi’;

会先通过name辅助索引定位到B+树的叶子节点得到id=5，再通过聚集索引定位到行记录。所以，其实扫了2遍索引树。而非聚簇索引由于叶子节点存储的是数据存储的地址，所以该sql查询只需要检索一次索引树。

3.总结

MyISAM和InnoDB都使用B+树来实现索引：

MyISAM的索引与数据分开存储

MyISAM的索引叶子存储指针，主键索引与普通索引无太大区别

InnoDB的聚集索引和数据行统一存储

InnoDB的聚集索引存储数据行本身，普通索引存储主键

InnoDB一定有且只有一个聚集索引