欢迎关注个人主页：逸狼
创造不易，可以点点赞吗~
如有错误，欢迎指出~
目录
mysql索引
索引 类似于书的 目录,引入 索引 是为了 提高查询的速度
select这样的操作,默认是按照"遍历"的方式来查询,即时间复杂度为O(n),但这里的 读的是硬盘,而在数据结构里的O(n) ,遍历的是内存
代价
- 引入索引 需要消耗额外的 存储空间
- 引入索引后,确实能提高 查询的效率 ,但可能会影响 增删改的 效率(有时会 更快,有时会更慢,也或者 没变化)
比如: 通过条件判断 的方式来 删除 delete from student where id = 5; 其中where id=5 背后就有查询操作
索引有利有弊,实际开发中 还是推荐使用 索引
- 硬盘往往不是主要矛盾
- 对于增删改查 也不一定都是 负面影响,也可能会 触发一些正面效果
- 很多业务场景 查询的 频率 要比 增删改 要高很多
查看索引
show index from 表名;
主键自带索引
unique 和 foreign key 也自带索引
创建索引
create index 索引名 on 表名(列名);
创建索引 其实是一个危险操作,针对 空表 或者 表中只有 较少数据(几千,几万...)创建索引 谈不上危险 但是一旦数据量 比较大( 千万级别),此时创建索引操作 可能会触发 大量的硬盘IO,直接把机器卡死了, 所以在 最初建表时 要哪些索引要提前规划好,创建好
删除索引
drop index 索引名 on 表名;
只能删除 自己创建的索引,不能删除自动生成的 ,删索引也是 危险操作.
索引背后的数据结构
所谓"构建索引" 其实是 引入一些数据结构 对数据进行存储,从而 提高查找速度~
二叉搜索树 和 哈希表 的查找效率都很高,但是都不适合 给数据库做索引
原因:
- 二叉搜索树 最大的问题在于 "二叉",当要保存的 元素多的时候,会使整个树的 高度变高(高度变高,比较的次数就会变多,伤硬盘~)
- 哈希表 最大的问题在于 只能进行"相等" 查询,无法进行 < >这样的'范围查询',也无法进行 like 模糊查询(哈希表 是通过哈希函数 把查询的key 映射成 数组下标)
B树
也写做 B-树(这里的 - 是连接符)
B树 是N叉搜索树(每个节点 ,可以有 多个子树,树的度是 N, 这样降低了树的高度)
每个节点不是 存储一个key值,而是会存多个 ,某个节点保存了 N个key,就能延伸出 N+1个子树,
和某个节点比较的时候,先一次硬盘IO,把所有的这个节点的内容都读出来,再在内存中比较,这里最主要的目的: 不是为了减少 比较的次数 而是要减少 硬盘IO的次数
B+树
B+树 ,为数据库 量身定做的数据结构 ,针对B树做的进一步改进的数据结构,B+树也是N叉搜索树
上图中的15是该B+树的最大值
若要进行 范围查询id>4 and id<10 ,从4开始,沿着链表往后遍历到10即可完成查询~
B+树与B树的区别
- B树 是有N个key,划分成N+1个区间 ,B+树 是有N 个key,划分出N个区间
- 父节点中的key值 会在下面的子节点中再次出现 (成为子节点最大值)
- B+树把叶子节点 像一个链表一样 连在一起了(此时进行 '范围查询' 就非常方便了)
B+树的优势
- N叉搜索树,树的高度比较低,此时硬盘IO次数就比较少
- 叶子节点是全集, 并且用链表结构连接,非常便于范围查询
- B+树 所有查询都要落在叶子节点上完成的 ,任何一次查询,经历的IO次数和比较次数 都是差不多的,查询的开销稳定(稳定意味着 成本容易被预估出来)
- B+树的叶子节点是全集,所以 非叶子节点上不必存储 "数据行"(比如:数据行: "1 ,张三, 男, 100分),只需要存储索引列的 key即可(非叶子节点占据的空间小,可以直接加载到内存中,进一步减少了硬盘IO的访问次数)
mysql事务
事务 是用来解决一类 特殊场景的问题(有些场景,完成某个操作,需要多个sql 配合完成,例如 转账)
事务 是把多个执行的SQL 打包成一个'整体',这个整体 在执行的过程中要做到 要么整个执行完,要么一个都不执行 (这里的"一个都不执行"实际上是"回滚"机制),避免出现 类似于" 转账转一半" 的情况.
回滚 :当sql执行到一半发现出错了 ,数据库会自动进行"还原操作"(相当于把前面执行过的sql给 '撤销'了,最终效果就像 一个sql都没有执行的效果). 回滚操作 只是针对 事务 来说,不能将想 "drop database "这样的操作 回滚回来
事务 涉及的四个核心特性:
- 原子性(最重要的特性),上面提到的 '整体'即原子性.
- 一致性 ,事务执行的前后数据库中的数据都是'合法状态',不会出现 非法的临时结果的状态
- 持久性.事务执行完毕后,就会修改 硬盘上的数据,事务都是会持久生效的.
- 隔离性, 描述了 多个事务 并发执行的时候 相互之间产生的影响是怎样的
隔离性详细解释
并发执行: mysql是一个 '客户端- 服务器'结构的程序, 一个服务器通常会给多个客户端 同时提供服务,因此 很可能,多个客户端会同时向 这个服务器提交事务来执行,服务器就要同时执行这些多个事务,此时就是 并发执行.
若此时 同时执行的事务 恰好是针对同一个表 进行 增删改查 ,此时就可能会引入 一些问题:
脏读 ,不可重复读 , 幻读.
脏读
指一个事务读取的数据是 "脏数据"(过时的数据)
举例: 有两个事务A和B 并发执行,
其中 事务A 是针对某个表的数据 进行修改 .A执行过程中,B也去读取这个表的数据, 当B读完后,A把表中的数据又改成了别的,
这样就会导致B读到的数据 不是最终的"正确数据" ,而是临时性的 "脏数据"
解决方法: 给写操作加锁(即在修改的时候,不能读)
不可重复读
指的是 一个事务里 多次读取的结果不一样
举例: 有三个事务ABC ,
事务A执行完一个修改操作,提交数据,事务B再执行,读取刚才A提交的数据,
在B读取的过程中,事务C又对刚才A修改的数据 再次做出了修改
对B来说,后续读到的这个数据 和第一次读到的是不一样的.
解决方法: 给读操作加锁(一个事务在读取数据的过程中,其他事务不能修改它正在读的数据)
幻读
幻读 是不可重复读的特殊情况
举例"事务A在读取数据时 ,事务B 新增 或 删除了一些数据
A多次读取的数据虽然 一样,但是 '结果集'不同
解决方法:'串行化'(只要是 读的时候,就不要有任何操作.)
隔离性的四个级别
针对上面3个问题, mysql 提供了四个隔离级别,可以通过 配置文件来设置当前服务器的隔离级别
设置不同的隔离级别 会使事务间的并发执行产生的影响有差别
read uncommitted 读未提交
一个事务可以读取 另一个事务未提交的数据,此时就可能会产生 脏读.不可重复读,幻读 三个问题
但是此时,多个事务并发执行的程度是 最高的,执行速度也最快.
read committed 读已提交
一个事务只能读取另一个事务提交之后的数据(给写操作加锁),此时会产生 不可重复读 和 幻读 两个问题(脏读问题解决了),此时并发程度会降低,执行速度会变慢,但是事务之间的隔离性提高了(事物之间影响变小了,得到的数据更准确了)
repeatable read 可重复读
相当于给读操作和写操作都加锁了.此时可能会产生 幻读问题(解决了脏读和不可重复读问题),
并发程度进一步降低,执行速度进一步变慢, 事务的隔离性进一步提高了.
serializable 串行化
所有事务都是在服务器上一个接一个的执行的,此时解决了脏读,不可重复读,幻读问题
并发程度最低,执行速度最慢,隔离性最高,数据最准确
