mysql一索引概述

Table of Contents

索引：帮我们高效查询数据的数据结构。

衡量索引高效的标准：IO渐进复杂度 

1，索引的种类：

2，索引的优点：

3，索引的缺点：

4，B-Tree和B+tree

5，MYISAM引擎与INNODB引擎

---

 

索引：帮我们高效查询数据的数据结构。

衡量索引高效的标准：IO渐进复杂度 

1，索引的种类：

• hash索引   1，有hash冲突  2，无法作范围查询 
• FullText索引： 全文索引      
• R-Tree:空间索引

2，索引的优点：

•   提高检索效率
•   降低排序成本 --排序分组主要消耗的是我们的内存和CUP资源

3，索引的缺点：

•  增加更新索引的IO量
•  增加调整索引所致的计算量
•  存储空间消耗

4，B-Tree和B+tree

 

b tree 每个节点都是二元组（key,date） 每个节点都存储数据

 

b+tree 1，只有叶子节点都会存储数据二元组（key,date）， 2，每个叶子节点都会指向下一个叶子节点（方便范围查询）

 

B-Tree和B+tree区别

1，B+节点关键字搜索采用闭合区间
2，B+非叶节点不保存数据相关信息，只保存关键字和子节点的引用
3，B+关键字对应的数据保存在叶子节点中
4，B+叶子节点是顺序排列的，并且相邻节点具有顺序引用的关系

 

5，MYISAM引擎与INNODB引擎

引擎介绍   mysql的Engine是 基于表的  不是基于库的

	Innodb	Myisam
存储文件	.frm 表定义文件  .ibd 数据文件	.frm 表定义文件  .myd 数据文件  .myi  索引文件
锁	表锁、行锁	表锁
事务	ACID	不支持
CRDU	读、写	读多
count	扫表	专门存储的地方
索引结构	B+ Tree	B+ Tree

MYISAM引擎 三个文件

frm :表结构，数据类型

myi: 非聚集索引，没有建索引就没有内容，有索引则建立一个b+tree   叶子节点是（key,MYD文件中的key对应的地址）

myd:MYD文件 数据文件

 

 

INNODB引擎 两个文件

frm :表结构，数据类型

idb:已主键为索引来组织数据，每个叶子节点存储的是真实数据。   本身用来存储数据的树就是一个索引

 

 

 

InnoDB使用的是聚簇索引（所谓聚簇索引，就是指主索引文件和数据文件为同一份文件），将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用"where id = 14"这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。

若对Name列进行条件搜索，则需要两个步骤：

第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。

第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。

 

　我们重点关注聚簇索引，看上去聚簇索引的效率明显要低于非聚簇索引，因为每次使用辅助索引检索都要经过两次B+树查找，这不是多此一举吗？聚簇索引的优势在哪？

　　1 如果修改的是非索引字段的数据，只需要修改主键索引树的叶子节点，而不需要修改辅助索引树

       2 由于行数据和叶子节点存储在一起，这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键Id来组织数据，获得数据更快。

　　2 辅助索引使用主键作为"指针" 而不是使用地址值作为指针的好处是，减少了当出现行移动或者数据页分裂时辅助索引的维护工作，使用主键值当作指针会让辅助索引占用更多的空间，换来的好处是InnoDB在移动行时无须更新辅助索引中的这个"指针"。也就是说行的位置（实现中通过16K的Page来定位，后面会涉及）会随着数据库里数据的修改而发生变化（前面的B+树节点分裂以及Page的分裂），使用聚簇索引就可以保证不管这个主键B+树的节点如何变化，辅助索引树都不受影响。

 

https://blog.csdn.net/perfectsorrow/article/details/80150672