网站备案 写共享可以吗,wordpress前端投稿上传图片,爱企业工商信息查询系统,营销型网站建设优化创作不易#xff0c;本篇文章如果帮助到了你#xff0c;还请点赞 关注支持一下♡#x16966;)!! 主页专栏有更多知识#xff0c;如有疑问欢迎大家指正讨论#xff0c;共同进步#xff01; #x1f525;c系列专栏#xff1a;C/C零基础到精通 #x1f525; 给大… 创作不易本篇文章如果帮助到了你还请点赞 关注支持一下♡)!! 主页专栏有更多知识如有疑问欢迎大家指正讨论共同进步 c系列专栏C/C零基础到精通 给大家跳段街舞感谢支持ጿ ኈ ቼ ዽ ጿ ኈ ቼ ዽ ጿ ኈ ቼ ዽ ጿ ኈ ቼ ዽ ጿ ኈ ቼ 目录 索引概述索引的使用 为什么不使用 AVL、 红黑树作为索引为什么不使用哈希作为索引B 树B树聚簇索引、非聚簇索引最左匹配原则MySQL 索引的优缺点索引的优化索引失效 慢 SQL 优化 索引概述
什么是索引可以用于优化查询
是一种已经排好序的数据结构映射结构根据 key 找到 value
如果不使用索引mysql 查询就会从第一个开始逐个去查询全表查询 每次查询都会产生磁盘的 I/O 交互 为什么要使用索引? 就是为了缩短查询的时间。就像书本的目录一样。 数据量和数据结构有很大的关系。 mysql索引使用什么 有使用B树的索引有使用hash表的 引擎决定了索引的类型 MySQL 常见引擎与索引类型
MyISAM、InnoDBB 树Memory/heapHash 表
存储引擎形容数据库表 索引的使用
创建索引
create index 索引名 on 表名(列名);删除索引
drop index 索引名 on 表名;使用 explian关键字查看是否使用索引进行检索type RES时代表使用索引检索还可关注 key、row、extra等字段查看影响查询性能的主要指标。 为什么不使用 AVL、 红黑树作为索引
红黑树的本质仍是二叉树当数据量比较大时红黑树的层数比较高每次读取节点都是在做磁盘 IO
并且每个节点只能存储一个数据但是在索引的数据结构中一个节点需要存两个值一个是key 用来存节点的值一个是value 存索引所在行的磁盘地址查到后就能获取到其value内的值即地址。 为什么不使用哈希作为索引
哈希表不支持排序操作哈希表不能进行范围查询如果发生哈希冲突效率变低 B 树
B 树相比于二叉树每个节点横向上能够存储更多的索引元素在树的高度相同的情况下B 树能够存储更多的数据。
B 树的每个节点都存储索引 key 和数据地址 value导致层数变高。 B树
B树 将所有的索引都存放在叶子节点上B树的节点上索引顺序从左到右依次递增B树只有叶子节点存储索引 key 和数据地址 value非叶子节点存储冗余索引冗余索引的值为主键 注意所有在冗余索引中出现的主键值都会在叶子节点中再现。设置冗余索引目的为了使树高尽可能小所以一层要尽可能多的放索引按照B树这种结构一个节点16KBdata元素会占用空间。如果不存储data只存储索引就可以存储更多索引树可以分更多叉
对比红黑树 B树的一个节点可以存放多个元素比红黑树更低磁盘 IO 次数更少。
对比 B 树 B 树不利于范围查询B树可以通过双向指针进行范围查找只需要遍历叶子节点即可完成数据遍历 B树查找索引的过程 ① 把根节点所有的索引从磁盘加载到内存中如图的15、56、77磁盘加载到内存就是一次磁盘 IO ② 在内存中比对比对过程可用二分查找发现在15-56之间注意他俩之间白色框存储的是其指向节点在磁盘中的文件地址 ③ 把指向节点所有索引再次加载到内存 ④ 重复直到 当定位到目标索引元素30后直接用其data中的物理地址去访问索引所在行的磁盘地址 高版本 Mysql 在启动时就将所有的非叶子节点即冗余节点加载到内存中 聚簇索引、非聚簇索引
聚簇索引是节点聚合数据即在存储节点的位置直接存储数据
非聚簇索引是节点只存储地址需要通过地址间接寻址来获取实际存储的数据 一张表只允许存在一种类型的索引聚簇索引或非聚簇索引 在 Innodb 引擎下主键索引是聚簇索引表结构文件 FRM索引与数据文件 IBD 在 MyISAM 引擎下主键索引是非聚簇索引表结构文件 FRM索引文件 MYIindex数据文件 MYDdata 聚集索引相比于非聚集索引查找效率一般更高直接在当前文件即可查询到数据不用再去数据文件中查询。
聚簇索引的插入速度严重依赖于插入顺序按照主键的顺序插入是最快的方式否则影响性能。 对于 Innodb 表一般主键定义为自增 整型不可更新二级索引访问需要进行两次索引查找第一次找到主键值第二次根据主键值找到行数据回表因此多使用主键查询 如果没有定义主键那么会使用第一非空的唯一索引NOT NULL and UNIQUE INDEX作为聚簇索引 如果既没有主键也没有合适的非空索引那么InnoDB会自动生成维护一个包含了ROW_ID值的列作为聚簇索引 最左匹配原则
联合索引将多个字段列组合成为一个索引。
在使用联合索引时需要遵循最左匹配原则即按照最左优先的方式进行索引查询。
最左匹配原则要求查询的列必须从索引中最左的列开始并且不能跳过中间列否则索引失效。 联合索引底层为排好序的 B树如果没有给出第一字段就无法快速找到该数据应该处在的节点因为优先以第一字段排序只看第二字段并不是从左到右排好序的需要扫描所以节点 MySQL 索引的优缺点
优点:
1.方便查询极大地缩短查找的时间
缺点:
1.创建索引。那么维护索引就需要消耗时间数据量越多维护成本越高2.索引占用空间较大每个节点都是 16Kb 的页大小会影响表的最大存储量。3.对表中的数据进行增加和删除修改。索引要动态维护会降低数据维护速度
索引的优化
1.对于需要经常更新的字段避免为他建立过多的索引2.数据量小的表不用创建索引不一定能比全表查询效率高3.字段中存在重复数据例如性别不需要创建索引4.主键索引最好是自增方式插入新数据时对原数据的大量操作5.尽量保证将索引设置为唯一无需大量查找
索引失效
在如下情况可能会导致索引失效
违背最左匹配原则索引列中使用函数进行计算查询条件中出现了类型转换索引列和非索引列掺杂使用like 模糊查询%在最左或两边联表查询时两个表的字符集不同
慢 SQL 优化
1.优先使用索引2.是否索引失效3.将数据量较大的表进行垂直或水平拆分4.加 redis 缓存 大家的点赞、收藏、关注将是我更新的最大动力 欢迎留言或私信建议或问题。
大家的支持和反馈对我来说意义重大我会继续不断努力提供有价值的内容如果本文哪里有错误的地方还请大家多多指出(●◡●)
