存储引擎

Myiasm

Myiasm是mysql默认的存储引擎，不支持数据库事务，行级锁，外键；底层采用B+树实现；插入更新需锁表，效率低，查询速度快，Myisam使用的是非聚集索引。

非聚集索引

下图于网络中摘抄：

非聚集索引原理图

Innodb

官方介绍：https://dev.mysql.com/doc/refman/8.0/en/innodb-introduction.html

特性

Feature Support
B-tree indexes Yes
Backup/point-in-time recovery (Implemented in the server, rather than in the storage engine.) Yes
Cluster database support No
Clustered indexes Yes
Compressed data Yes
Data caches Yes
Encrypted data Yes (Implemented in the server via encryption functions; In MySQL 5.7 and later, data-at-rest encryption is supported.)
Foreign key support Yes
Full-text search indexes Yes (Support for FULLTEXT indexes is available in MySQL 5.6 and later.)
Geospatial data type support Yes
Geospatial indexing support Yes (Support for geospatial indexing is available in MySQL 5.7 and later.)
Hash indexes No (InnoDB utilizes hash indexes internally for its Adaptive Hash Index feature.)
Index caches Yes
Locking granularity Row
MVCC Yes
Replication support (Implemented in the server, rather than in the storage engine.) Yes
Storage limits 64TB
T-tree indexes No
Transactions Yes
Update statistics for data dictionary Yes

Innodb支持事务，锁的力度支持表锁、行级锁；底层为B+树实现，适合处理多重并发更新操作，普通select都是快照读（MVCC的功劳），快照读不加锁。InnoDb使用的是聚集索引等等。

架构

innodb-architecture

聚集索引

使用聚集索引查询为什么查询速度会变快？

使用聚簇索引找到包含第一个值的行后，便可以确保包含后续索引值的行在物理相邻

建立聚集索引有什么需要注意的地方吗？

在聚簇索引中不要包含经常修改的列，因为码值修改后，数据行必须移动到新的位置，索引此时会重排，会造成很大的资源浪费

InnoDB 表对主键生成策略是什么样的？

优先使用用户自定义主键作为主键，如果没有，则自动先检查表中是否有唯一索引且不允许存在null值的字段，如果没有，则InnoDB会为表默认添加一个名为row_id隐藏列作为主键，数据类型大小为6Byte。

MVCC

官方介绍：https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html

https://blog.csdn.net/SnailMann/article/details/94724197

https://blog.csdn.net/chen77716/article/details/6742128

索引

索引类型

主键索引

二级索引（辅助索引）

联合索引

最左匹配原则

如联合索引a + b，通常在索引树中存储如下：

联合索引

可以很清楚的看到a是由有序的，而b只是局部有序，即在a确定的情况下，b是有序的。假设我们的查询条件是a = 1 and b = 2，那么a、b都能走上索引，因为在知道a的情况下，b是有序的，所以可以用上索引，当查询条件是a > 1 and b = 2时，a可以用上索引，而b不行，因为a是范围查询，当a是范围查找是，b是无序的，因为a值不相等。

索引数据结构

B+树 & Hash表

BTree 索引与 Hash 索引有什么区别？

B树

创建索引的注意事项

1.选择合适的字段创建索引：

2.被频繁更新的字段应该慎重建立索引。

虽然索引能带来查询上的效率，但是维护索引的成本也是不小的。 如果一个字段不被经常查询，反而被经常修改，那么就更不应该在这种字段上建立索引了。

3.尽可能的考虑建立联合索引而不是单列索引。

因为索引是需要占用磁盘空间的，可以简单理解为每个索引都对应着一颗 B+树。如果一个表的字段过多，索引过多，那么当这个表的数据达到一个体量后，索引占用的空间也是很多的，且修改索引时，耗费的时间也是较多的。如果是联合索引，多个字段在一个索引上，那么将会节约很大磁盘空间，且修改数据的操作效率也会提升。

4.注意避免冗余索引 。

冗余索引指的是索引的功能相同，能够命中索引(a, b)就肯定能命中索引(a) ，那么索引(a)就是冗余索引。如（name,city ）和（name ）这两个索引就是冗余索引，能够命中前者的查询肯定是能够命中后者的 在大多数情况下，都应该尽量扩展已有的索引而不是创建新索引。

5.考虑在字符串类型的字段上使用前缀索引代替普通索引。

前缀索引仅限于字符串类型，较普通索引会占用更小的空间，所以可以考虑使用前缀索引带替普通索引。

索引的底层实现是B+树，为何不采用红黑树，B树?

索引失效条件