当前位置:   article > 正文

《mysql篇》--索引事务

《mysql篇》--索引事务

索引

索引的介绍

索引是帮助MySQL高效获取数据数据结构,是一种特殊的文件,包含着对数据表里所有记录的引用指针,因为索引本身也比较大,所以索引一般是存储在磁盘上的,索引的种类有很多,不过如果没有特殊说明,我们一般认为索引是一个B+树的结构。

索引的作用

优势:

  • 可以提高列检索的效率,降低搜索成本。
  • 对提高数据库的性能有很大的作用。
  • 通过索引对数据进行,排序也可以大大提高排序效率
  • 数据库中的表、数据、索引之间的关系,类似于书架上的图书、书籍内容和书籍目录的关系。

劣势:

  • 会占用磁盘空间
  • 有时可能会比较危险,在创建索引时需要对现有的数据,进行大规模的从新整理(调整存储的数据结构),如果当前是一个空表,或者数据不多,创建索引一般没有什么问题,如果这个表本来就很大,此时创建索引就需要对所有数据进行重新调整结构,重新存储,就有可能把服务器给卡住,一般来说,创建索引都是在创建表时就规划好的。

索引的使用

查看索引

show index from 表名;

举例:

  1. create table demo(
  2. id int primary key,
  3. age int,
  4. name varchar(20));
  5. show index from demo;

创建索引

create index 索引名字 on 表名(列名);

举例:

  1. create index index_id on demo(id);
  2. show index from demo;

//这里的举例只是为了讲解

删除索引

drop index 索引名 on 表名;

  1. drop index index_id on demo;
  2. show index from demo;

//主键,unique,外键都是会自动生成索引的

索引内部的原理和逻辑

如果没有特殊说明,我们一般认为索引是一个B+树的结构。

二叉搜索树

博主在之前的博客中有详细讲解过二叉搜索树,如果有兴趣可以去看看。

B树

在将B+树之前我们要先了解一些B树,B树又叫多路平衡查找树,他并不是一棵二叉树,而是一棵多叉树,每个结点有M个子节点,M称为B树的阶,

B树的特点包括:

  • 每个节点可以有多个子节点,这使得B树能够优化大块数据的读写操作。
  • B树的所有叶子节点都在同一层,保持了树的平衡。
  • B树中的关键字从小到大排列,每个结点上有M个key,划分出M+1个区间
  • 叶子节点不包含关键字,指向这些外部结点的指针为空,叶子结点的数目正好等于树中所包含的关键字总个数加1。

每个结点可以看作是一个区间,从无穷小到无穷大,每一个关键字都会将这个区间划分,每个小区间又可以向下延申出子结点,又或者说每个结点里所包含的关键字大小,都在其对应的父结点,的相应的小区间里

举例:查找7

首先从根结点开始,7比10小,所以在10左边的区间,然后继续查找比较,7比3大,在3右边的区间,继续查找比较,在这个结点中可以查找到7,查找结束。

进行查询的时候,就可以直接从根结点出发,判定当前要查找的数据在节点上的哪个区间,决定下一步往哪里走,进行添加/删除元素可能会涉及到结点的拆分和结点的合并

//B树可以有效的减少访问硬盘的次数,从而大大提高检索的性能

B+树

  • 为了进一步提高检索的性能,在B树的基础上改造得到了B+树,B+树是B树的改进,针对数据库量身定做
  • B+树也是一个N叉搜索树,一个结点上存在N个key,划分成N个区域
  • 每个节点上N个key中,最后一个就相当于当前子树的最大值
  • 父节点上的每个key都会以最大值的身份,在子节点的对应区间中存在(key可能会重复出现)
  • 叶子节点这一层,包含整个树的数据全集
  • B+树会以链表的形式,把叶子节点串起来(此时就方便我们进行遍历,也方便按照范围取出一个子集)

假如说要查询id>26 and id<62的就可以根据head进行查找

B+树的优点(相较于B树以及哈希,红黑树)

  • N叉搜索树,树的高度有限,降低了IO次数,增加了效率
  • 范围查找效率较高
  • 所有查询的最终结果都落到子节点,查询次数较稳定
  • 由于叶子结点是全集,会把行数据只存储在叶子节点上,非叶子节点只是存储一个用来排序的key(比如存个id)

事务

事务的介绍

我们先来举一个例子,假如我们现在要去银行把钱转账给另一个人,那么把这个操作简化为MySQL语句的话,就是我的账户删除一条数据,另一个人的账户插入一条数据,那么假如中间出现了错误,我的账户少了,另一个人的账户没有变,这样的场景显然是不合理的。

事务就是将多条sql语句打包为一个整体,要么都执行,要么都不执行,事务把多个sql打包为一个整体来执行,称之为“原子性”(意为不可再拆分)。

也就是说,在执行事务时如果其中有一条或者多条语句出现错误,那么所有执行的语句都会回滚(回到执行前的状态),收到影响的数据也会回到事务开始之前的状态,当所有语句都执行成功后事务也就顺利进行了

 事务不仅仅有原子性,还有一些其他方面的特性

  1. 原子性:回滚的方式,保证这一系列操作都能执行正确,或者恢复如初
  2. 一致性:事务执行之前,和之后要保证数据的合理性,比如不能出现前文例子中的,一方账户的金额少了,一方账户金额不变
  3. 持久性:事务做出的修改都是在硬盘上持久保存的,重启服务器,数据仍然存在,事务执行的修改任然是有效的
  4. 隔离性:一个事务的执行不能被其他事务干扰,数据库在并发执行时事务之间是隔离的

事务的使用

隐式事务

没有明确的开始和提交的标志,具有自动开始和提交事务的功能,在默认状态下mysql就是自动提交事务

显式事务

和隐式事务不同需要自己,手动开始事务和提交(commit)/回滚(rollback),在使用显式事务时要先将自动提交事务关掉,方法就是将变量autocommit的值改为0

首先准备一个表

具体步骤如下

  1. #第一步开始事务
  2. start transaction;
  3. #第二步编写事务中的sql语句
  4. update test2 set gpa = 3.8 where id = 6;
  5. update test2 set gpa = 4.1 where id = 5;
  6. #第四步提交事务
  7. commit;
  8. #rollback,回滚事务,将数据回到执行事务之前

并发事务时会遇到的问题

脏读

一个事务A正在写数据的过程中,另一个事务B读取了同一个数据,接下来事务A又修改了数据,导致B之前读的数据是一个无效的数据/过时的数据(也称为脏数据)

解决脏读的核心思路,就是对写操作进行加锁(规定在A写的时候B不可以读),之前A和B时并发执行的,在加锁之后,并发程度和效率就降低了,但是隔离性和数据准确性提高了

不可重复读

在并发执行事务的过程中,如果事务A在内部多次读取同一个数据的时候,出现不同的情况,这种情况就是不可重复读,即事务A在两次相邻的读取操作之间,有一个事务B修改了数据并提交了事务。

刚刚写加锁时,我们只是规定在写的时候不能读,但是没有规定在读的时候不能写,那么我们想要解决不可重复读就要再进一步加锁,也就是规定在读的时候也不能写

这样之后,并发程度和效率就又降低了,但是隔离性和数据准确性依然提高了

幻读

一个事务A执行过程中,两次读取操作,数据内容虽然没改变,但是结果集变了(比如又多出一个文件),虽然我们刚刚约定了,在读的时候能写,在写的时候不能读但是,当事务A再写A文件的时候事务B不能读A文件,但是事务B可以读B文件

这时我们只好从根本上解决,将两个事务完全分离,比如A执行完了之后才能执行B,这样就完全没有并发,效率自然是最低,但是隔离性和数据准确性都是最高

事务的隔离级别

一个事务和另一个事务的隔离程度称作隔离级别,

  • read uncommitted(读未提交)  没有加锁,并发程度最高,速度最快,隔离性最低,准确性最低
  • read committed(读已提交) 引入写加锁,只能读写完之后提交的版本,并发程度降低,速度降低,隔离性提高了,准确性提高了
  • repeatable read(可重复读)  引入了写加锁和读加锁,写的时候不能读,读的时候不能写,并发程度又进一步降低了,速度降低,隔离性提高,准确性提高
  • serializable(串行化)严格的按照串行的方式,一个一个的执行事务,并发事务最低(没有并发),速度最低,隔离性最高,准确性最高

//四种隔离级别对应上面的三个问题,隔离级别越高,并发程度越低,准确性越高,速度越慢。

oracle默认的事务隔离级别是:read committed

mysql默认的事务隔离级别是:read committed

以上就是博主对mysql--索引事务的分享,如果有不懂的或者有其他见解的欢迎在下方评论或者私信博主,也希望多多支持博主之后和博客!!

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/笔触狂放9/article/detail/903351
推荐阅读
相关标签