索引本质
索引是帮助Mysql高效获取数据的排好序的数据结构
Innodb存储索引的特点
. 索引大节点的存储大小,默认为16kb
. int整型存储大小: 8b
. Mysql索引指针的大小: 6b
. 索引+指针一般是成对出现的,一个节点大概可以存储16kb/(8b+6b)=1170个单索引元素
SHOW GLOBAL STATUS LIKE 'Innodb_page_size';
运行结果:

索引数据结构
. 二叉树
. 红黑树
. Hash表
. B-Tree
二叉树

红黑树 -二叉平衡树

缺点:
- 数据量很大的话,树的高度不可控,则磁盘IO的次数也不可控,所以这种情况下不适合在红黑树中存储
B-Tree
. 叶节点具有相同的深度,叶节点的指针为空
. 所有索引元素不重复
. 节点中的数据索引从左到右递增排列

B+Tree(B-Tree变种)
. 非叶子节点不存储data,只存储索引(冗余),可以放更多的索引
. 叶子节点包含所有索引字段
. 叶子节点用指针连接,提高区间访问的性能

B+Tree的优点:
. 相同数据量,B+Tree的高度小于B树
. 千万级的数据量,B+Tree最多经历2~4次磁盘IO就能找到
B+Tree叶子节点连接指针的作用:
. B+Tree叶子节点指针是双向循环链表(Mysql底层做了优化)
. 每一个小节点都是满足二叉树的特点,从左到右依次递增,很好地支持了范围查找,顺着指针批量查找数据
Hash表
. InnoDB存储引擎支持自适应哈希索引,用户仅能开启此特性,不能对其进行人工干预
. 哈希索引只能用来搜索等值的查询,而对于其他查找类型,比如范围查找,是不能使用哈希索引的
. 排序和Order By 也不能很好的支持
Mysql索引实现方式
. BTree
. Hash

Mysql存储引擎
存储引擎最终是修饰表的,数据库级别的存储引擎在表没有明确指定引擎的时候,默认使用数据库级别的存储引擎设置
数据存储路径
windows : data目录下
lunix : 默认 /var/lib/mysql
MyISAM存储引擎索引实现
. MyISAM索引文件和数据文件是分离的(非聚集)

文件结构:
frm :存储表结构
MYD:存储数据
MYI:存储索引
InnoDB存储引擎索引实现
. InnoDB索引实现(聚集-数据和结构包含在一起)
. 表数据文件本身就是按B+Tree组织的一个索引结构文件
. 聚集索引-叶节点包含了完整的数据记录
.为什么InnoDB表必须有主键,并且推荐使用整型的自增主键?
1. 首先由表数据存储结构有关,其本身就是按照B+Tree组织的,如果没有主键,Mysql会自动生成一列唯一的索引,维护一个隐藏的rowId字段,作为主键索引2. InnoDB存储引擎是索引组织表,也就是说数据文件本身就是按照B+树方式存放数据的。其中,B+树的键值为主键,若在建立的时候没有显式地指定主键,则InnoDB存储引擎会自动创建一个6字节的列作为主键。因此在InnoDB存储引擎中,可以将B+树索引分为聚集索引和辅助索引,无论何种索引,每个页的大小都为16KB。3. 索引查找涉及到大量的比较,整型比较的时候比较快,整型占用空间小,自增的索引元素,插入性能也比较高,只需要往后面进行元素存储,如果前面的节点已经满了16kb,中间插入比较慢,涉及运算较多(节点分裂,树平衡等)
. 为什么非主键索引结构叶子节点存储的是主键值?(一致性和节省存储空间)
- 插入数据前需要维护索引表,需要保证数据的一致性,只需要维护一份完整的数据

文件结构:
frm:存储表结构
ibd:存储索引+数据
底层结构:
- 主键索引:

特点:
. 节点存储的是索引所在行的其他所有的字段
2.辅助索引:

特点:
. 节点存储的是索引所在行的主键
3.联合索引:

特点:
. 按照建索引字段的顺序,逐一比较
.尽量使用联合索引,少维护索引树
