前言

本篇介绍MySQL的索引与事务，了解底层索引B+树的基本思想, 了解事务的4大特征, 隔离性解决事务并发等问题; 如有错误，请在评论区指正，让我们一起交流，共同进步！

文章目录

前言
1. 数据库索引
- 1.1 B树
- 1.2 B+树
2. 事务
总结

本文开始

1. 数据库索引

索引: 能够加快查找的速度,快速搜索数据
索引底层不一定线性的,数据像一条一条的,还可能是树型结构的, 像B+树;

这里我们简单了解一下B树,B+树的思想;
了解B+树, 先说一下B树;

1.1 B树

B树: 是一种N叉搜索树, 每个节点中存储多个key, 根据key划分子树,左树中key小于父节点中key,右树中key大于父节点中key; 节点中key增多, 每层就子树增多, 使树的层数减少, 数据库查找读取IO次数减少,增加了查找的速度;
B树的特点:(参考下图理解特点)

树的每个节点可以存储多个key值,树的每个key存储着一条数据 (n个key划分n+1个区间)
左树中key小于父节点中key,右树中key大于父节点中key
树的父节点有n个key, 它的孩子节点根据区间划分产生n+1个孩子

区间划分:
左子树是小于30的范围的, 中间子树是大于30小于40的范围, 右子树是大于40的范围; 子树依次往下划分;

1.2 B+树

B+树: B树的进一步优化, 查找数据比较稳定 => B+树的数据都存储在叶子节点, IO访问次数基本一致(不会像B树那样次数不一);

B+树的特点:(参考下图理解特点)

每个节点有多个key值, 它的数据都存储在叶子节点(没有左右孩子), 可以认为非叶子节点存储着数据的序号, 查找真正的数据必须到叶子节点上; IO访问次数基本一致(稳定性);(n个key划分n个区间)
一个节点保存多个Key值, 降低树的高度, 减少了IO访问次数;
B+树叶子节点首尾相连, 类似一个链表(下图蓝框部分)
叶子节点存储完整的数据, 非叶子节点只存储key本身
B+树的所有数据构成链表, 方便范围查找
B+树的非叶子节点只存储key,不是完整的数据, 只有访问叶子节点是进行IO访问, 所以减少了IO访问次数

区间划分:以图为例
规则: 左子树的区间小于20的值, 但是父节点的20必须在子树中, 并且是子树的最大值;
右子树区间范围20到30, 且它的最大值为父节点中的key(30);
剩下范围重复上述步骤;

2. 事务

事务: 多条sql语句组成的整体, 执行事务要么全部成功, 要么失败; 如果执行一半失败, 会进行回滚操作, 回复到原来的sql语句;

事务的4大特性:

原子性: 整体,不能分割;
一致性: 更改前后数据一样
例如: A向B转账: A账号减100, B账号就加100; 减少增加数据一样;
持久性: 修改后的数据不会再变;
A账号减少100后不会改变
隔离性: 解决事务并发产生的问题,

隔离性解决事务并发的经典问题:
① 脏读问题
问题描述:
事务A正在修改文件, 还没有提交, 事务B此时读取文件(同一份文件), 会产生 “脏读” 问题;
提交后的文件, 可能与A没有提交前写的文件不相同;
解决: 给事务A, 写加锁
为了让B读取的文件不变, 给事务A写加锁; 这样在提交后, 文件与B看到的相同(A正在修改的时候的文件);
② 不可重复读问题
问题描述:
事务A写完文件, 提交了文件(第一次提交), 事务B读取文件, 事务B正在读取文件, 此时事务A再次修改文件, 并提交文件(第二次提交), 事务B读着读着文件内容改变了(变成事务A修改的新内容), 此时就产生了 “不可重复读” 的问题; <=> 事务B多次读取文件不一致就是不可重复读的问题 <=>同一个事务多次读取, 读取的结果数据不一样
解决: 给事务B读加锁
给B加锁, 保证了B在读取文件的过程中, 文件内容不会改变;
③ 幻读问题
问题描述:
事务A写加锁, 事务B读加锁的情况下, 事务B正在读取文件, 事务A创建新的文件写这个文件, 此时事务B读着读着就发现事务A写的新文件, 此时就是 “幻读” 问题; (事务A写了新文件, 但是旧文件不会改变, 新文件是在旧文件的下面位置) <=> 同一个事务读取同一份数据, 数据值(原来的数据)一样, 数据集(可能会有新的数据文件+原来数据)不一样;
解决;
串行化, 放弃并发处理多个事务, 一个一个执行事务;(先执行事务A, 再执行事务B…)