MySQL调优
MySQL调优1、回顾下索引的使用
什么是索引?
索引是一种让你能在 MySQL中 快速实现数据查询的这样一种数据结构
如果是将这个MySQL存储的数据必做一本书那么我们的索引 就是这本书的目录 我们要查询这本书的目录 那么通过这个索引就能很快的定位这个位置
前面我们讲MySQL的时候 我们说 这个MySQL本身是基于文件系统的 简单的说就是 存储到文件中的
我们的文件是存储到 硬盘上的硬盘上就涉及到IO操作
IO的本身的效率就很低
就拿读取数据来说 我们的IO读取这个数据 包括了 磁盘的旋转 和 磁盘的寻道
磁盘的旋转的时间很短磁盘的寻道时间很长这个其实就是IO效率低的原因
那么我们说了 索引其实就是一种数据结构 通过这个数据结构就能快速的去定位数据的位置所以他能提升这个效率
索引在什么时候创建呢?
当我们在开发系统的时候 明确的感觉到这个数据的查询 需要很长的时间的时候 那么这个时候 我们就需要创建这个索引来 进行效率的提升索引的创建不是随便创建的 一定是依赖于SQL语句的查询条件来创建的 也就是说 应该先有SQL语句 再有索引那么有人就有疑问了 那么这个SQL语句什么时候是慢的呢? 可以通过执行计划(Explain)来追踪SQL语句评判这个SQL语句的执行下利率的高低
索引是不是 创建的越多越好呢?
当然不是索引一旦创建 就意味着 需要数据来进行同步 这个同步 也是需要消耗这个计算机资源的、索引创建的越多 那么SQL语句在执行的时候 需要的分析 也就越多....所以这样也能降低效率
回顾下 SQL语句的运行流程是啥?
JDBC--->连接MySQL服务器---->发送SQL语句---->SQL粗优化---->分析SQL语句--->计算出花费值(cost)--->选择花费值小的路径---->执行SQL语句
一个SQL语句是否做索引是不是固定的? 不是固定的(表的数据量、索引的最左前缀原理、条件值有关)
2、索引的分类
单值索引
我们的索引的列只有一个的时候 这个称为单值索引
在innodb引擎下 我们的表在生成的时候 自动会生成 主键索引
联合索引
索引的列有多个列构成这种称为联合索引
createtable t_user(
id integer primary key auto_increment,
name varchar(100),
age int,
position int,
index index1(name),
index index2(name,age),
index index3(name,age,position)
)
alter table t_user add index index1(name)
alter table t_user add index index2(name,age)
alter table t_user add index index3(name,age,position)
3、索引的底层原理为什么是B+树
3.1、索引的底层为什么不是二叉树
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=img%2F1720057593368.png&pos_id=img-sKo5eXp5-1725268055547
二叉树的特点是小数在左边 大数在右边如果这个数据是递增的话 那么在二叉树中的排列就如上图所示
这个索引本身也是存储到 硬盘上的要读取这个数据的话 是不是也涉及到IO操作那么如果遍历的节点过多就意味着
IO的次数可能变多，所以在极端的情况下 这个二叉树的效率是很低的 就类似咋们的全表扫描
而且我们在单体的架构中 推荐使用的就是 自增长作为主键 恰好就是这个极端情况所以这个二叉树并不适合做索引
3.2、索引的底层为什么不是红黑树
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=img%2F1720058059899.png&pos_id=img-k6qxM8Nd-1725268055547
这个红黑树和二叉树相比较而言 红黑树做索引的效率要高一些 ，但是红黑树的平衡也不彻底如果是数据量过大的话 那么依然存在要遍历很多节点的问题这个效率本身也不高这就是为什么不使用红黑树来做索引的底层
3.3、索引的底层为什么不是B树
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=img%2F1720058504480.png&pos_id=img-gCEVpIYJ-1725268055547
在B树种有个深度这个概念
深度的意思是:每个节点上能存的数据的个数 = 深度-1
B树有什么特点呢?
B树打破了传统树一个节点 只能存储 一个数据的问题在一个节点上能存储多个数据而且这多个数据是有大小顺序的
他充分的利用 一个节点 存储多个数据的这个特性 来让我们找数据的时候 遍历更少的节点 从而提高这个数据的查询效率
但是这个B树是有一个致命的缺陷的?
B树最大的缺点就是不擅长做范围内的查询 .....
3.4、索引的底层为什么是B+树
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=img%2F1720059689144.png&pos_id=img-d3Av3Ce6-1725268055548
B+树的特点：
所有的数据都存储到了 叶子节点
节点和节点之间存在双向链表
B+树中存在冗余节点这个冗余节点的存储 其实就是典型的 以空间换时间 使用冗余节点来快速定位我们需要查询的数据的位置
B+树还解决了 B树不擅长做范围内查询的这个问题
假设当前的索引的列为NULL 那么这个数据是存储到 B+树上的那一个位置的呢?如果索引的列为空 那么这个数据将存储到叶子节点的最左侧
假设SQL语句是这样写的 select * from t_user where index is null?这个SQL是否会走索引呢? 不会 因为这个是不能通过冗余节点去定位这个位置的
4、索引的最左前缀原理
5、各种场景的调优题目
[*]from t_user where index is null? 这个SQL是否会走索引呢? 不会 因为这个是不能通过冗余节点去定位这个位置的
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]