文章目录
😊 @ 作者：Lion J
💖 @ 主页： https://blog.csdn.net/weixin_69252724?spm=1000.2115.3001.5343
🎉 @ 主题： 数据库mysql（高级部分）
⏱️ @ 创作时间：2024年01月24日
文章目录
- 文章目录
- 一、mysql的服务架构？
-
- [1. 连接层](#1. 连接层)
- [2. 服务层](#2. 服务层)
- [3. 引擎](#3. 引擎)
- [4. 物理文件层](#4. 物理文件层)
- 二、引擎
- 三、索引
- 总结
提示：以下是本篇文章正文内容，下面案例可供参考
一、mysql的服务架构？
服务架构是mysql的骨架结构, 分为连接层, 服务层, 引擎层, 数据文件层
1. 连接层
连接层主要用于处理与客户的连接，授权认证，以及安全认证
2. 服务层
完成sql服务的核心服务, 如相关的sql接口, 以及数据的缓存, sql的分析, 以及内置函数的执行, 是否利用索引查询
3. 引擎
负责与文件层进行交互操作, 是否支持索引, 锁定水平...
4. 物理文件层
在文件系统(硬盘)上存储数据, 日志
二、引擎
1. 概述
在mysql中用到的存储机制, 是否支持索引, 支持的锁定水平等各种功能技术, 不同的技术与配置方式叫做引擎
2. 两种主要引擎
●InnoDB
●MyISAM
三、索引
在数据量大(万级数据)可以高效的查询数据
1.概念
数据库中维护的特定查找算法的数据结构叫做索引, 他是一种排好序的快速查找的数据结构
2.索引的原理
类似与书上的目录, 不用再寻找书中的数据时每次一页一页的翻, 可以直接通过目录来减小数据的范围,逐渐筛选出结果, 做到高效查找自己想要的数据;
图例:
将数据库中的数据与索引库中的数据一一对应, 提高检索效率
3. 索引的优劣势
●优势
- 索引可以快速的提高检索效率，降低数据库的IO成本(从系统文件上读取)
- 索引对查询纪录结果进行排序, 分组, 降低原本mysql结果排序对CPU的消耗
●劣势
- 由于创建索引之后, 索引相当一张表, 保存主键与索引字段,以及指向实体表的纪录的物理地址, 会占用磁盘空间
- 数据的增删改不仅会改变实体表的纪录, 还会改变索引关系表(索引树)的纪录, 所以会降低更新表数据的速度，造成实际业务的拖延，增加数据库压力
4. 索引的分类
这里以mysql数据库为例
1> 主键索引
顾名思义就是将表中的主键当作索引列, 数据库会自动再主键上添加索引
语句
mysql
#增加
alter table [表名] add primary key
#删除
alter table [表明] drop primary key
2>单值索引
可以给某一列添加索引, 就是最常用索引
语句
mysql
#添加
create index 索引名 on 表名(列名)
#删除
drop index 索引名 on 表明如:create idnex admin_account_index on admin(account)
单值索引查询效率比主键索引性能低
原因: 主键索引的值在整个表中必须是唯一的，这使得数据库可以更快地定位到特定的行。相比之下，单值索引可能不保证唯一性，因此查询可能需要检查更多的行
3>唯一索引
唯一索引这里的唯一指的是这一列的纪录是唯一的, 可以想象成主键索引的低配版, 列里的值允许null
语句
mysql
create unique index on 表名(列名)
drop index 索引名 on 表名唯一索引与前面例子类似,唯一就是要求
4>组合索引（复合索引）
●概念
组合索引可以想象为多个单值索引, 但是总体来说, 组合索引比多个单值索引的开销更小, 当行数远远大于列数时候, 可以适当的添加组合索引
语句
mysql
create index on 表名(列名,列名,列名)
drop index on 表明●组合索引最左前缀原
假如有三个列abc,添加组合索引ab, 那么在将组合索引的列作为查询条件时, 必须要出现最左侧列, 不然组合索引不生效
演示
(应该叫组合索引, 图中口误🤣)
这是组合索引生效例子
组合索引失效
5>全文索引
由于mysql在模糊查询时候, 一般的索引都不生效, 所以有专门应对该问题产生了全文索引
语法
mysql
CREATE FULLTEXT INDEX 索引名 ON 表名(字段名) WITH
create fulltext index 索引名 on 表明(列) preset图示:
先使用单值索引, 索引列名name
再使用全文索引
注意：
在使用全文索引时,进行模糊查询语法稍微不一样
SELECT 结果 FROM 表名 WHERE MATCH(列名) AGAINST('搜索词')
5. 索引的数据结构
索引数据结构是B+树的结构
为什么不能是二叉树?
因为数据库里的主键一般都是自增的, 而根据二叉树的性质知道, 此时的索引树将会向一边倾斜, 导致高度非常高(和链表一样), 反而查询效率更慢
为什么不能是红黑树?红黑树虽然可以通过子旋转,但是还是会向一边来加元素, 问题同上
用B+树,非叶子结点上放数据的索引, B+树的性质刚好可以让一个非叶子结点放大量的索引;而将数据放到一个个的叶子结点里,所有叶子结点(数据之间有链指针)
这样可以在全表扫描时,查询某一索引时,快速锁定该索引, 再向下获取该索引对应数据在sql范围查询时, 也可以通过链指针快速得到范围内的数据
图示:
6. 聚簇索引与非聚簇索引
●聚簇索引:
只在执行sql查询操作时, 可以通过索引直接获取数据, 比如InnoDB里的主键索引(一级索引)
聚簇是设计: InnoDB,索引与数据如下
●非聚簇索引:
指的是,索引存储与数据存储是分离的, 比如在Myisam引擎,
＞索引与数据关系如下
innodb与myisam虽然聚簇式设计与非聚簇式索引, 但是并不代表查询时候的索引都是聚簇索引与非聚簇索引,仅仅是根据两种思想设计的
innodb反例:
如一个表 字段 a(主键),b,c,字段c(单值索引)
selelct b,c from test where c = 33
该sql通过c的索引树查询到的索引结点数据是主键id, 再需要通过主键id重新查询一下,该sql查询中, c索引就是非聚簇索引
myisam反例:
例子同上
select id from test where id = 1
该种查询就直接查询到对应的索引结点,再通过索引结点直接获取内存里的数据物理地址