博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
MYSQL INDEX 是那么简单的吗?
阅读量:2169 次
发布时间:2019-05-01

本文共 869 字,大约阅读时间需要 2 分钟。

平时我们在使用INDEX的时候都是那么理所应当,而原理估计了解的人不是太多。今天来说说MYSQL 的索引的一些东西,或许你已经知道了,或许你还不知道,follow me .

自从MYSQL 5.7 后,INDEX的建立不在是从顶向下的方式,而是自下向上的方式来建立索引。

一般建立一个二级索引需要的步骤

1 从聚集索引中读取相关的数据条目来进行二级索引的构建

2 进行与索引相关的归并排序

3 插入二级索引需要的记录

而传统的索引构建的方法自上而下,他会产生很多的页面的分割和页面的合并的操作,而这样的操作对于建立索引的代价是比较昂贵的。MYSQL 5.7 构建索引的方法变为从下往上的方式来进行。(用图来演示)

1  插入一个页 叶子节点

2 当叶子节点插满后,将叶子节点的指针插入到父节点 

3 然后产生另外一个叶子节点,在将数据插满后连接到父节点,周而复始

4 通过上面周而复始的操作,就产生了二级的索引

但问题是大部分数据库都有一个填充因子(有的数据库不这么叫),在MYSQL 里面默认的比率是 100, 而聚簇索引则以默认 百分之6的填充因子进行设置,也就是说一个页面有百分之6是空的,为未来的DML操作进行保留。

这就牵扯到一个事情,即使默认的索引填充率应该怎么设置的问题,如果设置成80%,就是有20%的空间要留给未来的数据升级使用。

一般来说可以根据具体的数据库的大部分表的更新的度来进行 innodb_fill_factor 来进行设置。一般从 70% -90% 不等来设计,如果表是静态表,基本上不更新则 90% 即可,如果经常更新,并且有些字段的值的变动较大,则可以考虑70%。后续中的页的在拆分和合并的操作。

所以调整innodb_fill_factor 操作的主要目的

1 防止也的 splits 和 merges

2 不要经常进行数据插入位置的research

3 如果没有splits 和 merges 则 redo log 的压力就会比较小,不会进行redo log的操作

缺点也是显而易见的,就是会浪费空间。

转载地址:http://fhazb.baihongyu.com/

你可能感兴趣的文章
【NLP学习笔记】(一)Gensim基本使用方法
查看>>
【NLP学习笔记】(二)gensim使用之Topics and Transformations
查看>>
【深度学习】LSTM的架构及公式
查看>>
【python】re模块常用方法
查看>>
剑指offer 19.二叉树的镜像
查看>>
剑指offer 20.顺时针打印矩阵
查看>>
剑指offer 21.包含min函数的栈
查看>>
剑指offer 23.从上往下打印二叉树
查看>>
剑指offer 25.二叉树中和为某一值的路径
查看>>
剑指offer 60. 不用加减乘除做加法
查看>>
Leetcode C++《热题 Hot 100-14》283.移动零
查看>>
Leetcode C++《热题 Hot 100-15》437.路径总和III
查看>>
Leetcode C++《热题 Hot 100-17》461.汉明距离
查看>>
Leetcode C++《热题 Hot 100-18》538.把二叉搜索树转换为累加树
查看>>
Leetcode C++《热题 Hot 100-19》543.二叉树的直径
查看>>
Leetcode C++《热题 Hot 100-21》581.最短无序连续子数组
查看>>
Leetcode C++《热题 Hot 100-22》2.两数相加
查看>>
Leetcode C++《热题 Hot 100-23》3.无重复字符的最长子串
查看>>
Leetcode C++《热题 Hot 100-24》5.最长回文子串
查看>>
Leetcode C++《热题 Hot 100-26》15.三数之和
查看>>