【MySQL 数据库】MySQL索引特性(二)页目录(B和B+树)(非)聚簇索引 索引操作
文章目录
- 📝索引的理解
- 1.1 建立测试表
- 1.2 插入多条记录
- 1.3 查看插入结果
- 1.4 中断一下---为何IO交互要是Page
- 二,理解Page
- 2.1理解单个Page
- 2.2 理解多个Page
- 三,页目录
- 3.1 **单页情况**
- 3.2 **多页情况**
- 3.3 复盘一下
- 四,B+ vs B
- 4.1 B树
- 4.2 B+树
- 五、聚簇索引 VS 非聚簇索引
- 六、索引操作
- 6.1创建主键索引
- 6.2 唯一索引的创建
- 6.3 普通索引的创建
- 6.3 全文索引的创建
- 6.4 查询索引
- 6.5 删除索引
- 🚩总结
📝索引的理解
1.1 建立测试表
create table if not exists user ( id int primary key, --一定要添加主键哦,只有这样才会默认生成主键索引age int not null,name varchar(16) not null);
mysql> show create table user \G*************************** 1. row ***************************Table: userCreate Table: CREATE TABLE `user` (`id` int(11) NOT NULL,`age` int(11) NOT NULL,`name` varchar(16) NOT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 --默认就是InnoDB存储引擎
1 row in set (0.00 sec)
1.2 插入多条记录
注意,我们并没有按照主键的大小顺序插入哦
mysql> insert into user (id, age, name) values(3, 18, '杨过');Query OK, 1 row affected (0.01 sec)mysql> insert into user (id, age, name) values(4, 16, '小龙女');Query OK, 1 row affected (0.00 sec)mysql> insert into user (id, age, name) values(2, 26, '黄蓉');Query OK, 1 row affected (0.01 sec)mysql> insert into user (id, age, name) values(5, 36, '郭靖');Query OK, 1 row affected (0.00 sec)mysql> insert into user (id, age, name) values(1, 56, '欧阳锋');Query OK, 1 row affected (0.00 sec)
1.3 查看插入结果
mysql> select * from user; #发现竟然默认是有序的!是谁干的呢?排序有什么好处呢?
+----+-----+-----------+
| id | age | name |
+----+-----+-----------+
| 1 | 56 | 欧阳锋 |
| 2 | 26 | 黄蓉 |
| 3 | 18 | 杨过 |
| 4 | 16 | 小龙女 |
| 5 | 36 | 郭靖 |
+----+-----+-----------+
5 rows in set (0.00 sec)
1.4 中断一下—为何IO交互要是Page
为何MySQL和磁盘进行IO交互的时候,要采用Page的方案进行交互呢?用多少,加载多少不香吗?
如上面的5条记录,如果MySQL要查找id=2的记录,第一次加载id=1,第二次加载id=2,一次一条记录,那么就需要2次IO。如果要找id=5,那么就需要5次IO。
但,如果这5条(或者更多)都被保存在一个Page中(16KB,能保存很多记录),那么第一次IO查找id=2的时候,整个Page会被加载到MySQL的Buffer Pool中,这里完成了一次IO。但是往后如果在查找id=1,3,4,5等,完全不需要进行IO了,而是直接在内存中进行了。所以,就在单Page里面,大大减少了IO的次数。
你怎么保证,用户一定下次找的数据,就在这个Page里面?我们不能严格保证,但是有很大概率,因为有局部性原理。
往往IO效率低下的最主要矛盾不是IO单次数据量的大小,而是IO的次数。
二,理解Page
2.1理解单个Page
MysQL中要管理很多数据表文件,而要管理好这些文件,就需要先描述,在组织,我们目前可以简单理解成一个个独立文件是有一个或者多个Page构成的。
不同的Page,在MysQL中,都是16KB),使用prev和next构成双向链表
因为有主键的问题,MysQL会默认按照主键给我们的数据进行排序,从上面的Page内数据记录可以看出,数据是有序且彼此关联的。
为什么数据库在插入数据时要对其进行排序呢?我们按正常顺序插入数据不是也挺好的吗?
插入数据时排序的目的,就是优化查询的效率。
页内部存放数据的模块,实质上也是一个链表的结构,链表的特点也就是增删快,查询修改慢,所以优化查询的效率是必须的。
正式因为有序,在查找的时候,从头到后都是有效查找,没有任何一个查找是浪费的,而且,如果运气好,是可以提前结束查找过程的。
2.2 理解多个Page
- 通过上面的分析,我们知道,上面页模式中,只有一个功能,就是在查询某条数据的时候直接将一整页的数据加载到内存中,以减少硬盘IO次数,从而提高性能。但是,我们也可以看到,现在的页模式内部,实际上是采用了链表的结构,前一条数据指向后一条数据,本质上还是通过数据的逐条
比较来取出特定的数据。 - 如果有1千万条数据,一定需要多个Page来保存1千万条数据,多个Page彼此使用双链表链接起来,而且每个Page内部的数据也是基于链表的。那么,查找特定一条记录,也一定是线性查找。这效率也太低了。
三,页目录
我们在看《谭浩强C程序设计》这本书的时候,如果我们要看<指针章节>,找到该章节有两种做法
- 从头逐页的向后翻,直到找到目标内容
- 通过书提供的目录,发现指针章节在234页(假设),那么我们便直接翻到234页。同时,查找目录的方案,可以顺序找,不过因为目录肯定少,所以可以快速提高定位
- 本质上,书中的目录,是多花了纸张的,但是却提高了效率
- 所以,目录,是一种“空间换时间的做法”
3.1 单页情况
针对上面的单页Page,我们能否也引入目录呢?当然可以
那么当前,在一个Page内部,我们引入了目录。比如,我们要查找id=4记录,之前必须线性遍历4次,
才能拿到结果。现在直接通过目录2[3],直接进行定位新的起始位置,提高了效率。现在我们可以再次
正式回答上面的问题了,为何通过键值MySQL 会自动排序?
- 可以很方便引入目录
3.2 多页情况
MysQL中每一页的大小只有16KB,单个Page大小固定,所以随着数据量不断增大,16KB不可能存下所有的数据,那么必定会有多个页来存储数据。
在单表数据不断被插入的情况下,MySQL 会在容量不足的时候,自动开辟新的Page来保存新的数据,然
后通过指针的方式,将所有的Page组织起来。
需要注意,上面的图,是理想结构,大家也知道,目前要保证整体有序,那么新插入的数据,不一定会
在新Page上面,这里仅仅做演示。
这样,我们就可以通过多个Page遍历,Page内部通过目录来快速定位数据。可是,貌似这样也有效率问题,在Page之间,也是需要MySQL 遍历的,遍历意味着依旧需要进行大量的IO,将下一个Page加载到内存,进行线性检测。这样就显得我们之前的Page内部的目录,有点杯水车薪了。
那么如何解决呢?解决方案,其实就是我们之前的思路,给Page也带上目录。
- 使用一个目录项来指向某一页,而这个目录项存放的就是将要指向的页中存放的最小数据的键值。
- 和页内目录不同的地方在于,这种目录管理的级别是页,而页内目录管理的级别是行。
- 其中,每个目录项的构成是:键值+指针。图中没有画全。
存在一个目录页来管理页目录,目录页中的数据存放的就是指向的那一页中最小的数据。有数据,就可通过比较,找到该访问那个Page,进而通过指针,找到下一个Page。
其实目录页的本质也是页,普通页中存的数据是用户数据,而目录页中存的数据是普通页的地址。可是,我们每次检索数据的时候,该从哪里开始呢?虽然顶层的目录页少了,但是还要遍历啊?不用担心,可以在加目录页
这货就是传说中的B+树啊!没错,至此,我们已经给我们的表user构建完了主键索引。
随便找一个id=?我们发现,现在查找的Page数一定减少了,也就意味着IO次数减少了,那么效率也就提高了。
3.3 复盘一下
- Page分为目录页和数据页。目录页只放各个下级Page的最小键值。
- 查找的时候,自定向下找,只需要加载部分目录页到内存,即可完成算法的整个查找过程,大大减少了IO次数
InnoDB
在建立索引结构来管理数据的时候,其他数据结构为何不行?
- 链表?线性遍历
- 二叉搜索树?退化问题,可能退化成为线性结构
- AVL &&红黑树?虽然是平衡或者近似平衡,但是毕竟是二叉结构,相比较多阶B+,意味着树整体过高,大家都是自顶向下找,层高越低,意味着系统与硬盘更少的IO Page交互。虽然你很秀,但是有更秀的。
- Hash?官方的索引实现方式中,MysQL是支持HASH的,不过InnoDB和MyISAM并不支持.Hash跟进其算法特征,决定了虽然有时候也很快(O(1)),不过,在面对范围查找就明显不行,另外还有其他差别,有兴趣可以查一下。
- B树?最值得比较的是InnoDB 为何不用B树作为底层索引?
数据结构演示链接:https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
四,B+ vs B
4.1 B树
4.2 B+树
上面的图,是在网上找的,大家也可以搜一下。
目前这两棵树,对我们最有意义的区别是:
- B树节点,既有数据,又有Page指针,而B+,只有叶子节点有数据,其他目录页,只有键值和Page指针
- B+叶子节点,全部相连,而B没有
为何选择B+
- 节点不存储data,这样一个节点就可以存储更多的key。可以使得树更矮,所以IO操作次数更少。
- 叶子节点相连,更便于进行范围查找
五、聚簇索引 VS 非聚簇索引
MyISAM
存储引擎-主键索引
MyISAM
引擎同样使用B+树作为索引结果,叶节点的data域存放的是数据记录的地址。下图为MyISAM表的主索引,Co11为主键。
其中,MyISAM 最大的特点是,将索引Page和数据Page分离,也就是叶子节点没有数据,只有对应数据的地址。
相较于InnoDB 索引,InnoDB 是将索引和数据放在一起的。
--终端A
mysql> create database myisam_test;
Query OK, 1 row affected (0.02 sec)mysql> use myisam_test;mysql> create table mtest(-> id int primary key,-> name varchar(11) not null-> )engine=MyISAM; --使用engine=MyISAM
Query OK, 0 rows affected (0.02 sec)
--终端B
root-VMware-Virtual-Platform:/var/lib/mysql# ls myisam_test/ -al --mysql数据目录下
总计 20
drwxr-x--- 2 mysql mysql 4096 7月 30 20:57 .
drwx------ 21 mysql mysql 4096 7月 30 20:56 ..
-rw-r----- 1 mysql mysql 2842 7月 30 20:57 mtest_470.sdi --文件混淆:mtest_470.sdi 是 InnoDB 或第三方工具的临时文件,与 MyISAM 表无关。
-rw-r----- 1 mysql mysql 60 7月 30 21:03 mtest.MYD --该表对应的数据,当前没有数据,所以是0
-rw-r----- 1 mysql mysql 2048 7月 30 21:03 mtest.MYI --该表对应的主键索引数据
root-VMware-Virtual-Platform:/var/lib/mysql#
版本特性:MySQL 8.0+ 的 MyISAM 表不再生成 .frm,表结构由数据字典统一管理。
其中,MyISAM
这种用户数据与索引数据分离的索引方案,叫做非聚簇索引
下面是InnoDB
mysql> create database innodb_test;
Query OK, 1 row affected (0.00 sec)mysql> use innodb_test;
Database changedmysql> create table itest(id int primary key, name varchar(11) not null)engine=InnoDB;
Query OK, 0 rows affected (0.03 sec)mysql>
root-VMware-Virtual-Platform:/var/lib/mysql# ls innodb_test/ -al
总计 120
drwxr-x--- 2 mysql mysql 4096 7月 30 21:11 .
drwx------ 22 mysql mysql 4096 7月 30 21:10 ..
-rw-r----- 1 mysql mysql 114688 7月 30 21:11 itest.ibd --该表对应的主键索引和用户
root-VMware-Virtual-Platform:/var/lib/mysql#
数据,虽然现在一行数据没有,但是该表并不为0,因为有主键索引数据
其中,InnoDB这种用户数据与索引数据在一起索引方案,叫做聚簇索引
当然,MySQL除了默认会建立主键索引外,我们用户也有可能建立按照其他列信息建立的索引,一般这种索引可以叫做辅助(普通)索引。
对于MyISAM,建立辅助(普通)索引和主键索引没有差别,无非就是主键不能重复,而非主键可重复。下图就是基于My工SAM的co12建立的索引,和主键索引没有差别
同样,InnoDB 除了主键索引,用户也会建立辅助(普通)索引,我们以上表中的Col3 建立对应的辅助 索引如下图:
可以看到,InnoDB 的非主键索引中叶子节点并没有数据,而只有对应记录的key值。
所以通过辅助(普通)索引,找到目标记录,需要两遍索引:首先检索辅助索引获得主键,然后用主键
到主索引中检索获得记录。这种过程,就叫做回表查询
为何InnoDB
针对这种辅助(普通)索引的场景,不给叶子节点也附上数据呢?原因就是太浪费空间
了。
总结:
- 如何理解硬盘
- 如何理解柱面,磁道,扇区,磁头
- InnoDB 主键索引和普通索引
- MyISAM 主键索引和普通索引
- 其他数据结构为何不能作为索引结构,尤其是B+和B
- 聚簇索引 VS 非聚簇索引
六、索引操作
6.1创建主键索引
第一种方式-- 在创建表的时候,直接在字段名后指定 primary key
create table user1(id int primary key, name varchar(30));
第二种方式:-- 在创建表的最后,指定某列或某几列为主键索引
create table user2(id int, name varchar(30), primary key(id));
第三种方式:
create table user3(id int, name varchar(30));-- 创建表以后再添加主键
alter table user3 add primary key(id);
主键索引的特点:
- 一个表中,最多有一个主键索引,当然可以使符合主键
- 主键索引的效率高(主键不可重复)
- 创建主键索引的列,它的值不能为null,且不能重复
- 主键索引的列基本上是int
6.2 唯一索引的创建
- 第一种方式
第一种方式-- 在表定义时,在某列后直接指定unique唯一属性。
create table user4(id int primary key, name varchar(30) unique)
- 第二种方式
第二种方式-- 创建表时,在表的后面指定某列或某几列为uniquecreate table user5(id int primary key, name varchar(30), unique(name));
- 第三种方式
create table user6(id int primary key, name varchar(30));
alter table user6 add unique(name);
唯一索引的特点:
- 一个表中,可以有多个唯一索引
- 查询效率高
- 如果在某一列建立唯一索引,必须保证这列不能有重复数据
- 如果一个唯一索引上指定not null,等价于主键索引
6.3 普通索引的创建
第一种方式
create table user8(id int primary key,name varchar(20),email varchar(30),index(name) --在表的定义最后,指定某列为索引
);
第二种方式
create table user9(id int primary key, name varchar(20), email
varchar(30));alter table user9 add index(name); --创建完表以后指定某列为普通索引
第三种方式
create table user10(id int primary key, name varchar(20),
email varchar(30));-- 创建一个索引名为 idx_name 的索引
create index idx_name on user10(name);
普通索引的特点:
- 一个表中可以有多个普通索引,普通索引在实际开发中用的比较多
- 如果某列需要创建索引,但是该列有重复的值,那么我们就应该使用普通索引
6.3 全文索引的创建
当对文章字段或有大量文字的字段进行检索时,会使用到全文索引。MySQL提供全文索引机制,但是有要求,要求表的存储引擎必须是MyISAM,而且默认的全文索引支持英文,不支持中文。如果对中文进行全文检索,可以使用sphinx的中文版(coreseek)。
CREATE TABLE articles (id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,title VARCHAR(200),body TEXT,FULLTEXT (title,body))engine=MyISAM;
INSERT INTO articles (title,body) VALUES('MySQL Tutorial','DBMS stands for DataBase ...'),('How To Use MySQL Well','After you went through a ...'),('Optimizing MySQL','In this tutorial we will show ...'),('1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'),('MySQL vs. YourSQL','In the following database comparison ...'),('MySQL Security','When configured properly, MySQL ...');
- 查询有没有database数据
如果使用如下查询方式,虽然查询出数据,但是没有使用到全文索引
mysql> select * from articles-> where match (title, body) against ('database');
+----+-------------------+------------------------------------------+
| id | title | body |
+----+-------------------+------------------------------------------+
| 5 | MySQL vs. YourSQL | In the following database comparison ... |
| 1 | MySQL Tutorial | DBMS stands for DataBase ... |
+----+-------------------+------------------------------------------+
2 rows in set (0.01 sec)
可以用explain工具看一下,是否使用到索引
mysql> explain select * from articles where body like '%database%'\G
*************************** 1. row ***************************id: 1select_type: SIMPLEtable: articlespartitions: NULLtype: ALL
possible_keys: NULLkey: NULL <== key为null表示没有用到索引key_len: NULLref: NULLrows: 6filtered: 16.67Extra: Using where
1 row in set, 1 warning (0.00 sec)
- 如何使用全文索引呢?
mysql> SELECT * FROM articles-> WHERE MATCH (title,body) AGAINST ('database');
+----+-------------------+------------------------------------------+
| id | title | body |
+----+-------------------+------------------------------------------+
| 5 | MySQL vs. YourSQL | In the following database comparison ... |
| 1 | MySQL Tutorial | DBMS stands for DataBase ... |
+----+-------------------+------------------------------------------+
2 rows in set (0.00 sec)mysql>
通过explain来分析这个sql语句
mysql> explain SELECT * FROM articles WHERE MATCH (title,body) AGAINST -> ('database')\G
*************************** 1. row ***************************id: 1select_type: SIMPLEtable: articlespartitions: NULLtype: fulltext
possible_keys: title key: title <= key用到了titlekey_len: 0ref: constrows: 1filtered: 100.00Extra: Using where
1 row in set, 1 warning (0.00 sec)
6.4 查询索引
第一种方法:show keys from 表名
mysql> show keys from goods\G*********** 1. row ***********Table: goods
<= 表名
Non_unique: 0
<= 0表示唯一索引
Key_name: PRIMARY <= 主键索引
Seq_in_index: 1Column_name: goods_id <= 索引在哪列
Collation: ACardinality: 0Sub_part: NULLPacked: NULLNull:
Index_type: BTREE <= 以二叉树形式的索引
Comment:
1 row in set (0.00 sec)
第二种方法:
show index from 表名;
第三种方法(信息比较简略):desc 表名;
6.5 删除索引
第一种方法-删除主键索引:
alter table 表名 drop primary key;
第二种方法-其他索引的删除:
alter table 表名 drop index 索引名;索引名就是show keys
from 表名中的 Key_name 字段
mysql> alter table user10 drop index idx_name;
第三种方法方法: drop index 索引名 on 表名
mysql> drop index name on user8;
索引创建原则
- 比较频繁作为查询条件的字段应该创建索引
- 唯一性太差的字段不适合单独创建索引,即使频繁作为查询条件
- 更新非常频繁的字段不适合作创建索引
- 不会出现在where子句中的字段不该创建索引
其他索引:
- 复合索引(联合索引)
复合索引是指在表的多个字段上联合创建的索引,例如:
CREATE INDEX idx_name_age ON user(name, age); -- 对name和age创建复合索引
复合索引的底层按字段顺序构建B+树结构,查询时可利用多个字段加速检索。
- 最左匹配原则
复合索引的查询效率依赖于“最左前缀匹配”,即从索引的第一个字段开始匹配,必须满足连续匹配才能使用索引。
示例(基于 idx_name_age(name, age)
):
查询语句 | 是否使用索引 | 原因分析 |
---|---|---|
WHERE name = '张三' | 是 | 匹配索引第一个字段(最左前缀) |
WHERE name = '张三' AND age = 20 | 是 | 连续匹配索引的两个字段 |
WHERE age = 20 | 否 | 跳过第一个字段,无法匹配最左前缀 |
WHERE name LIKE '张%' AND age=20 | 是(部分) | 左模糊匹配可使用name部分,age仍能生效 |
WHERE name LIKE '%三' AND age=20 | 否 | 右模糊匹配破坏最左前缀,整个索引失效 |
核心规则:
- 索引字段的顺序至关重要(如
(name, age)
和(age, name)
完全不同)。 - 中断匹配(如跳过第一个字段)会导致后续字段无法使用索引。
- 左模糊查询(
LIKE '张%'
)不破坏最左匹配,右模糊(LIKE '%三'
)或全模糊(LIKE '%张%'
)会破坏。
- 索引覆盖(覆盖索引)
当查询的所有字段都包含在索引中时,MySQL无需回表查询数据行,直接通过索引即可返回结果,这就是“索引覆盖”。
示例(基于 idx_name_age(name, age)
):
-- 覆盖索引:查询的name和age都在索引中,无需回表
SELECT name, age FROM user WHERE name = '张三';-- 不覆盖索引:查询的address不在索引中,需回表取数据
SELECT name, age, address FROM user WHERE name = '张三';
优势:
- 避免回表操作(减少磁盘IO),显著提升查询效率。
- 适合高频查询的场景(如列表页展示固定字段)。
设计技巧:
- 将高频查询的字段加入复合索引(如
(name, age, status)
覆盖SELECT name, age, status
)。 - 避免索引字段过多(索引体积过大会降低写入性能)。
总结
- 复合索引:多字段联合索引,按顺序构建B+树。
- 最左匹配:必须从第一个字段开始连续匹配,否则索引失效。
- 索引覆盖:查询字段均在索引中,无需回表,效率极高。