mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-20 22:17:09 +08:00
Update 数据库索引.md
This commit is contained in:
parent
b11091909a
commit
dc0d755325
@ -1,14 +1,12 @@
|
||||
## 索引
|
||||
|
||||
## 什么是索引?
|
||||
**索引是一种用于快速查询和检索数据的数据结构。常见的索引结构有: B树, B+树和Hash。**
|
||||
|
||||
索引的作用就相当于目录的作用。打个比方: 我们在查字典的时候,如果没有目录,那我们就只能一页一页的去找我们需要查的那个字,速度很慢。如果有目录了,我们只需要先去目录里查找字的位置,然后直接翻到那一页就行了。
|
||||
|
||||
## 索引的优缺点分析
|
||||
## 为什么要用索引?索引的优缺点分析
|
||||
|
||||
### 索引的优点
|
||||
**索引最大的优点就是数据的检索效率高,这也是为什么要创建和使用索引的原因。毕竟大部分系统的读请求总是大于写请求的。**
|
||||
**可以大大加快 数据的检索速度(大大减少的检索的数据量), 这也是创建索引的最主要的原因。毕竟大部分系统的读请求总是大于写请求的。 ** 另外,通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性。
|
||||
|
||||
### 索引的缺点
|
||||
1. **创建索引和维护索引需要耗费许多时间**:当对表中的数据进行增删改的时候,如果数据有索引,那么索引也需要动态的修改,会降低SQL执行效率。
|
||||
@ -18,10 +16,7 @@
|
||||
|
||||
* B树的所有节点既存放 键(key) 也存放 数据(data);而B+树只有叶子节点存放 key 和 data,其他内节点只存放key。
|
||||
* B树的叶子节点都是独立的;B+树的叶子节点有一条引用链指向与它相邻的叶子节点。
|
||||
* B树的检索的过程相当于对范围内的每个节点的关键字做二分查找,
|
||||
可能还没有到达叶子节点,检索就结束了。
|
||||
而B+树的检索效率就很稳定了,任何查找都是从根节点到叶子节点的过程,
|
||||
叶子节点的顺序检索很明显。
|
||||
* B树的检索的过程相当于对范围内的每个节点的关键字做二分查找,可能还没有到达叶子节点,检索就结束了。而B+树的检索效率就很稳定了,任何查找都是从根节点到叶子节点的过程,叶子节点的顺序检索很明显。
|
||||
|
||||

|
||||
|
||||
@ -77,18 +72,13 @@ B+树是有序的,在这种范围查询中,优势非常大,直接遍历比
|
||||
### 聚集索引
|
||||
**聚集索引即索引结构和数据一起存放的索引。主键索引属于聚集索引。**
|
||||
|
||||
在Mysql中,InnoDB引擎的表的.ibd文件就包含了该表的索引和数据,
|
||||
对于InnoDB引擎表来说,该表的索引(B+树)的每个非叶子节点存储索引,
|
||||
叶子节点存储索引和索引对应的数据。
|
||||
在 Mysql 中,InnoDB引擎的表的 `.ibd`文件就包含了该表的索引和数据,对于 InnoDB 引擎表来说,该表的索引(B+树)的每个非叶子节点存储索引,叶子节点存储索引和索引对应的数据。
|
||||
|
||||
#### 聚集索引的优点
|
||||
聚集索引的查询速度非常的快,因为整个B+树本身就是一颗多叉平衡树,
|
||||
叶子节点也都是有序的,定位到索引的节点,就相当于定位到了数据。
|
||||
聚集索引的查询速度非常的快,因为整个B+树本身就是一颗多叉平衡树,叶子节点也都是有序的,定位到索引的节点,就相当于定位到了数据。
|
||||
|
||||
#### 聚集索引的缺点
|
||||
1. **依赖于有序的数据** :因为B+树是多路平衡树,如果索引的数据不是有序的,
|
||||
那么就需要在插入时排序,如果数据是整型还好,
|
||||
否则类似于字符串或UUID这种又长又难比较的数据,插入或查找的速度肯定比较慢。
|
||||
1. **依赖于有序的数据** :因为B+树是多路平衡树,如果索引的数据不是有序的,那么就需要在插入时排序,如果数据是整型还好,否则类似于字符串或UUID这种又长又难比较的数据,插入或查找的速度肯定比较慢。
|
||||
2. **更新代价大** : 如果对索引列的数据被修改时,那么对应的索引也将会被修改,
|
||||
而且况聚集索引的叶子节点还存放着数据,修改代价肯定是较大的,
|
||||
所以对于主键索引来说,主键一般都是不可被修改的。
|
||||
@ -220,13 +210,13 @@ ALTER TABLE table ADD INDEX index_name (num,name,age)
|
||||
|
||||
#### 3.尽可能的考虑建立联合索引而不是单列索引
|
||||
|
||||
因为索引是需要占用磁盘空间的,可以简单理解为每个索引都对应着一颗B+树。
|
||||
如果一个表的字段过多,索引过多,那么当这个表的数据达到一个体量后,
|
||||
索引占用的空间也是很多的,且修改索引时,耗费的时间也是较多的。
|
||||
因为索引是需要占用磁盘空间的,可以简单理解为每个索引都对应着一颗B+树。如果一个表的字段过多,索引过多,那么当这个表的数据达到一个体量后,索引占用的空间也是很多的,且修改索引时,耗费的时间也是较多的。如果是联合索引,多个字段在一个索引上,那么将会节约很大磁盘空间,且修改数据的操作效率也会提升。
|
||||
|
||||
如果是联合索引,多个字段在一个索引上,那么将会节约很大磁盘空间,且修改数据的操作效率也会提升。
|
||||
#### 4.注意避免冗余索引
|
||||
|
||||
#### 4.考虑在字符串类型的字段上使用前缀索引代替普通索引
|
||||
冗余索引指的是索引的功能相同,能够命中 就肯定能命中 ,那么 就是冗余索引如(name,city )和(name )这两个索引就是冗余索引,能够命中后者的查询肯定是能够命中前者的 在大多数情况下,都应该尽量扩展已有的索引而不是创建新索引。
|
||||
|
||||
#### 5.考虑在字符串类型的字段上使用前缀索引代替普通索引
|
||||
|
||||
前缀索引仅限于字符串类型,较普通索引会占用更小的空间,所以可以考虑使用前缀索引带替普通索引。
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user