目录
1.索引:
- 索引存在的意义就是
为了提高查询到效率. - 索引的作用就
类似与一本书的目录,通过目录就可以快速找到想要的内容.如果没有目录就只能一页一页的翻(遍历). -
使用索引付出的代价(有得就有失): a)
消耗了更多的空间,b)虽然提高了查找效率,但是降低了增删改的效率(因为插入修改记录,不仅需要修改硬盘的数据还要调整索引). - 虽然索引有一些代价但是仍然认为还是值得使用索引的,
因为大多数情况下查询的频率是高于增删改的.
1.1 索引的使用:
-
对于生产环境上比较大的表,一般都是建表之初就把索引都规划好,这样就会避免很多的低效操作.
-
查看索引,
show index from 表名;
-
创建索引,
create index 索引名 on 表名(列名); -
创建索引是一个低效的操作,如果表里的数据少,那么创建索引开销就不大;如果表里的数据很多,创建索引操作就会非常的耗时并且带来大量的硬盘IO,甚至会卡死数据库.
-
创建索引的时候也会创建出一些相关的数据结构.
-
删除索引,
drop index 索引名 on 表名; -
删除操作和刚才的创建操作类似都是比较低效的操作.
1.2 索引背后的核心数据结构:
哪些数据结构可以提高查找的效率:
1.哈希表, 增删查改都是O(1)
只能查询 值 相等的情况,但是如果是 < > between and 这类比较大小的范围查询就不行
2.二叉树 / 二叉搜索树, 查询速度最差是O(N)
AVL树 / 红黑树 (比较平衡的二叉搜索树) O(logN)
如果数据库数据特别多,上面的树就会比较的高 O(logN)
程序猿为了数据库索引量身定做了一个专门的数据结构 B+ 树.
1.2.1 先认识 B 树(N叉搜索树):
B树是一个N叉搜索树.每个节点上可能会包含N-1个值(也可能更少), N-1个值就把区间划分成了N份.这样分成N个叉的意义就是表示同样的数据集合的时候,比二叉树的高度要小很多,IO次数就降低了不少!
1.2.2 再认识 B+ 树(N叉搜索树):
| B 树 | B+ 树 |
|---|---|
B树每个节点N-1个值,就分出了N个区间
|
B+树N个值分成N个区间
|
B树中的值不会重复出现
|
B+树是可能重复出现的 (父元素的值会在子元素中以最大值/最小值的姿态出现) |
在叶子节点这里,B+树会把所有的叶子节点以链表的形式首尾相连,这个时候非常便于范围查找 |
|
正因为叶子节点是全集数据,只需要把每一行(每一条记录的完整的所有列关联到叶子节点上即可);非叶子节点只需要保存索引列(只存个id); |
|
| 非叶子节点占用空间非常小(相比于完整的数据集合),就可以在内存中缓存.因此这个时候查询就又进一步的减少硬盘IO. |
2.事务:
-
事务就是用来保证原子性的. -
原子性: 原子是不可分割的最小单位,使用原子来表示不能分割的基本单位.
-
数据库里面也有一些操作
希望可以按照原子的方式来执行,这种情况下就可以使用"事务"来实现 -
类似于转账操作就需要按照原子的方式来完成,要么执行全都执行完,要么都不执行(这里说的不执行不是真的没执行,而是执行一半如果出现问题可以自动的恢复如初)
-
事务就能保证,
当执行过程中出现问题的时候,自动的把前面的SQL执行的效果进行还原,恢复如初,这个操作叫做回滚(rollback); -
在
事务执行的过程中, MySQL会记录每一步都执行了啥,一旦出现问题就可以根据记录来回滚. -
既然可以回档, 为什么没有撤回呢? 为了实现事务, 其实需要付出很大的代价! 如果想要实现撤回的话, 意味着每一步都要付出这些代价. 撤回操作不是实现不了, 而是代价太大了, 不划算!
-
事务最核心的就是原子性, 事务的开启/提交/回滚,一般都是通过代码来控制的. -
四个特性:
4个特性 解释 原子性这就是事务存在的意义!, 能够 把多个SQL打包成一个整体,要么全都执行完,要么一个都不执行(如果执行过程中出错,则自动回滚)一致性 事务执行前后,数据处在一致的状态, (数据能够对的上) 持久性 事务进行的改动都是写到硬盘上的,不会随着程序重启/主机重启而丢失 隔离性多个事务并发执行的时候,事务之间能够保持"隔离",不会相互干扰
2.1 隔离性:
-
并发执行, 简单的理解就是同时做很多件事情.并发执行事务
可能存在问题,就需要隔离性. -
隔离性存在的意义就是
让并发执行事务的过程中,尽量不出问题(问题在可控范围之内)
2.1.1 脏读问题:
- 想象一个场景, 室友问我要作业,我把修改之前的作业发给他, 他用了之后,我把作业给改了.
- 上述就是一个脏读问题, 脏读数据就是一个
临时的数据, 不代表最终的结果. - 脏读: 一个事务A在修改数据,提交之前,另外一个事务B读取了数据,
此时A极有可能在提交的时候把数据给改了.此时事务B读到的就是"无效的数据"就称为脏读, 读到了脏数据. -
如何解决脏读问题: 结合上述场景,我就和室友约定好, 等我作业写好了再来找我要.在我写好之前,你们不要问我要!
这个操作就相当于是对 写操作加锁! - 在写加锁之前, 我的写操作和室友的读操作,就是完全并发的,此时
并发是最高的,隔离性是最低的! - 当写加锁之后,我写作业的时候,室友就不能问我要,
并发性降低了, 但是隔离性提高了! - 但是这又引入了新的问题, 不可重复读!
2.1.2 不可重复读问题:
- 概念:
在一个事务A中,多次读取同一个数据发现不一样!!! (读的过程中数据被人修改了) - 想象一个场景, 由于约定过写加锁, 室友在看我作业的时候,我又有了新的想法就把作业又给改了, 这个时候我再次发给室友, 他们就发现作业变了! , 这个过程就是不可重复读的问题.
-
不可重复读需要使用读加锁来解决, 我和室友约定我写作业的时候,你们不要问我要; 同时室友看我作业的时候, 我也不要去改. - 随着引入读加锁,
并发程度又进一步的降低了(效率降低),隔离性又提高了(数据准确性也提高了).
2.1.3 幻读问题:
- 想象一个场景, 刚刚和室友约定了写加锁和读加锁, 我还是闲不住, 室友读取文件A的时候, 我去修改文件B/新增删除文件…,只要不影响到大家正在读的那个数据就好了呀!(我是这么想的)
- 这样做虽然同学们直接读取的数据没有影响, 但是同学们会发现,俩次读虽然关系的数据一样
但是结果集变了.(第一次大家只能看到一个.java文化,现在看到了俩个.java文件) - 上面这种情况称之为
幻读问题, 可以看成是不可重复读的特殊情况. - 为了解决幻读问题, 我和室友约定好,他们读数据的时候,我就得关上电脑就要去摸鱼,作业一点都不能碰!
- 此时
并发程度最低了(串行执行的了)效率是最低的,隔离性是最高的,数据的准确性最高!
2.1.4 总结:
- 上述的脏读问题,不可重复读问题,幻读问题. 都是在并发执行事务中, 可能带来的影响.产生这些影响不一定是bug.
- 如果需求对于
数据精度要求不高,上述问题就不是bug,因此就可以让并发程度高一点,隔离性低一点,提高效率! - 如果需求对于
精度要求很高,上述问题就是可能是bug,因此就需要rag并发程度低一点,隔离性高一点,保证数据的可靠性! - 类似于转账,必须要精度很高,效率低一点都没事.
- 类似于抖音点赞/投币数,精度要求就不高.
2.1.5 隔离级别:
MySQL提供了隔离级别这个选项,给了四个档位, 让我们根据实际需求来选择不同的档位. 在MySQL的配置文件中 my.ini 进行配置,根据不同的需求场景,就可以分别设置不同的档位了.
| 选项 | 说明 |
|---|---|
| read uncommitted | 允许读未提交的数据,并发程度最高,隔离性最低,可能存在脏读/不可重复读/幻读问题 |
| read committed | 只能读取提交之后的数据, 相当于是写加锁,并发程度降低,隔离性提高,解决了脏读问题 |
repeatable read (默认)
|
相当于写加锁和读加锁了, 并发程度再次降低,隔离性再提高,解决了脏读/不可重复读问题 |
| serializable | 严格执行串行化, 并发程度最低,隔离性最高,解决了脏读/不可重复读/幻读问题,效率最低 |