1.索引:

1. 索引存在的意义就是为了提高查询到效率.
2. 索引的作用就类似与一本书的目录,通过目录就可以快速找到想要的内容.如果没有目录就只能一页一页的翻(遍历).
3. 使用索引付出的代价(有得就有失): a)消耗了更多的空间,b)虽然提高了查找效率,但是降低了增删改的效率(因为插入修改记录,不仅需要修改硬盘的数据还要调整索引).
4. 虽然索引有一些代价但是仍然认为还是值得使用索引的,因为大多数情况下查询的频率是高于增删改的.

1.1 索引的使用:

1. 对于生产环境上比较大的表,一般都是建表之初就把索引都规划好,这样就会避免很多的低效操作.

2. 查看索引, show index from 表名;

3. 创建索引, create index 索引名 on 表名(列名);

4. 创建索引是一个低效的操作,如果表里的数据少,那么创建索引开销就不大;如果表里的数据很多,创建索引操作就会非常的耗时并且带来大量的硬盘IO,甚至会卡死数据库.

5. 创建索引的时候也会创建出一些相关的数据结构.

6. 删除索引, drop index 索引名 on 表名;

7. 删除操作和刚才的创建操作类似都是比较低效的操作.

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.事务:

1. 事务就是用来保证原子性的.

2. 原子性: 原子是不可分割的最小单位,使用原子来表示不能分割的基本单位.

3. 数据库里面也有一些操作希望可以按照原子的方式来执行,这种情况下就可以使用"事务"来实现

4. 类似于转账操作就需要按照原子的方式来完成,要么执行全都执行完,要么都不执行(这里说的不执行不是真的没执行,而是执行一半如果出现问题可以自动的恢复如初)

5. 事务就能保证,当执行过程中出现问题的时候,自动的把前面的SQL执行的效果进行还原,恢复如初,这个操作叫做回滚(rollback);

6. 在事务执行的过程中, MySQL会记录每一步都执行了啥,一旦出现问题就可以根据记录来回滚.

7. 既然可以回档, 为什么没有撤回呢? 为了实现事务, 其实需要付出很大的代价! 如果想要实现撤回的话, 意味着每一步都要付出这些代价. 撤回操作不是实现不了, 而是代价太大了, 不划算!

8. 事务最核心的就是原子性, 事务的开启/提交/回滚,一般都是通过代码来控制的.

9. 四个特性:

   4个特性	解释
   原子性	这就是事务存在的意义!, 能够把多个SQL打包成一个整体,要么全都执行完,要么一个都不执行(如果执行过程中出错,则自动回滚)
   一致性	事务执行前后,数据处在一致的状态, (数据能够对的上)
   持久性	事务进行的改动都是写到硬盘上的,不会随着程序重启/主机重启而丢失
   隔离性	多个事务并发执行的时候,事务之间能够保持"隔离",不会相互干扰

2.1 隔离性:

1. 并发执行, 简单的理解就是同时做很多件事情.并发执行事务可能存在问题,就需要隔离性.
2. 隔离性存在的意义就是让并发执行事务的过程中,尽量不出问题(问题在可控范围之内)

2.1.1 脏读问题:

1. 想象一个场景, 室友问我要作业,我把修改之前的作业发给他, 他用了之后,我把作业给改了.
2. 上述就是一个脏读问题, 脏读数据就是一个临时的数据, 不代表最终的结果.
3. 脏读: 一个事务A在修改数据,提交之前,另外一个事务B读取了数据,此时A极有可能在提交的时候把数据给改了.此时事务B读到的就是"无效的数据"就称为脏读, 读到了脏数据.
4. 如何解决脏读问题: 结合上述场景,我就和室友约定好, 等我作业写好了再来找我要.在我写好之前,你们不要问我要! 这个操作就相当于是对 写操作加锁!
5. 在写加锁之前, 我的写操作和室友的读操作,就是完全并发的,此时并发是最高的,隔离性是最低的!
6. 当写加锁之后,我写作业的时候,室友就不能问我要,并发性降低了, 但是隔离性提高了!
7. 但是这又引入了新的问题, 不可重复读!

2.1.2 不可重复读问题:

1. 概念: 在一个事务A中,多次读取同一个数据发现不一样!!! (读的过程中数据被人修改了)
2. 想象一个场景, 由于约定过写加锁, 室友在看我作业的时候,我又有了新的想法就把作业又给改了, 这个时候我再次发给室友, 他们就发现作业变了! , 这个过程就是不可重复读的问题.
3. 不可重复读需要使用读加锁来解决, 我和室友约定我写作业的时候,你们不要问我要; 同时室友看我作业的时候, 我也不要去改.
4. 随着引入读加锁,并发程度又进一步的降低了(效率降低), 隔离性又提高了(数据准确性也提高了).

2.1.3 幻读问题:

1. 想象一个场景, 刚刚和室友约定了写加锁和读加锁, 我还是闲不住, 室友读取文件A的时候, 我去修改文件B/新增删除文件…,只要不影响到大家正在读的那个数据就好了呀!(我是这么想的)
2. 这样做虽然同学们直接读取的数据没有影响, 但是同学们会发现,俩次读虽然关系的数据一样但是结果集变了.(第一次大家只能看到一个.java文化,现在看到了俩个.java文件)
3. 上面这种情况称之为幻读问题, 可以看成是不可重复读的特殊情况.
4. 为了解决幻读问题, 我和室友约定好,他们读数据的时候,我就得关上电脑就要去摸鱼,作业一点都不能碰!
5. 此时并发程度最低了(串行执行的了)效率是最低的, 隔离性是最高的,数据的准确性最高!

2.1.4 总结:

1. 上述的脏读问题,不可重复读问题,幻读问题. 都是在并发执行事务中, 可能带来的影响.产生这些影响不一定是bug.
2. 如果需求对于数据精度要求不高,上述问题就不是bug,因此就可以让并发程度高一点,隔离性低一点,提高效率!
3. 如果需求对于精度要求很高,上述问题就是可能是bug,因此就需要rag并发程度低一点,隔离性高一点,保证数据的可靠性!
4. 类似于转账,必须要精度很高,效率低一点都没事.
5. 类似于抖音点赞/投币数,精度要求就不高.

2.1.5 隔离级别:

MySQL提供了隔离级别这个选项,给了四个档位, 让我们根据实际需求来选择不同的档位. 在MySQL的配置文件中 my.ini 进行配置,根据不同的需求场景,就可以分别设置不同的档位了.

选项	说明
read uncommitted	允许读未提交的数据,并发程度最高,隔离性最低,可能存在脏读/不可重复读/幻读问题
read committed	只能读取提交之后的数据, 相当于是写加锁,并发程度降低,隔离性提高,解决了脏读问题
repeatable read (默认)	相当于写加锁和读加锁了, 并发程度再次降低,隔离性再提高,解决了脏读/不可重复读问题
serializable	严格执行串行化, 并发程度最低,隔离性最高,解决了脏读/不可重复读/幻读问题,效率最低