MySql-高级( 面试问题简析) 学习笔记

10 篇文章 0 订阅
文章详细对比了MyISAM和InnoDB存储引擎的区别,解释了B+Tree索引的原理及优化,探讨了为何选择B+Tree而非Hash或B-Tree。还涉及了MySQL的事务特性、隔离级别、可重复读的实现、锁机制、死锁及数据库调优策略。
摘要由CSDN通过智能技术生成

1. MySql 中 MyISAM 和 InnoDB 存储引擎区别

1.1. MyISAM

  • 不支持事务
  • 不支持外键约束
  • 索引文件和数据文件是分开的,这样可以在内存里缓存更多的索引
  • 对查询的性能会更好,适用于少增改、多查询的需求

1.2. InnoDB

  • 支持事务
  • 聚簇索引
  • 强制要求有主键,支持外键约束
  • 大数据量可以分库分表、高并发可以读写分离、高可用可以主备切换这些都是基于 InnoDB

2. 索引的数据结构

2.1. B Tree索引

在这里插入图片描述

  • 每个节点要存放:
    • 数据
    • 指向下一节点的指针
    • 指向数据的指针

2.2. B+Tree索引

在这里插入图片描述

  • 非叶子节点要存放:
    • 下一节点的最小值
    • 指向下一节点的指针
  • 叶子节点要存放:
    • 具体的数据

2.3. MySql 做的优化

  • MySQL 在 B+Tree 的基础上,加了顺序访问的指针(如上图中 Q 连接的蓝色箭头),这样便于范围查找

3. 为什么使用B+Tree索引而不使用Hash索引?

  • 虽然Hash索引速度很快,但是它不支持范围查找
  • 上面说到加上了顺序访问指针的 B+Tree 是支持范围查找的

4. 为什么使用B+Tree索引而不使用B-Tree索引?

  • B+Tree每行存储的节点较多,原因如下:

    B-Tree结构中是将数据存储到了节点中,因此每行存的索引就变少了(规定每行存16kb)相应的深度(阶)比B+Tree深,会造成进行IO操作过多,影响性能。

  • 其次B+Tree中的叶子节点存在指针,由于指针的存在,在范围查找时,移动指针即可,而B-Tree不行

5. MyISAM 存储引擎索引实现

  • 因为索引文件和数据文件是分开的,所以在 B+Tree 的叶子节点中存储的不是具体的数据,而是数据对应的物理地址

6. InnoDB 存储引擎索引实现

  • InnoDB 数据文件本身也是一个索引文件,这个索引默认就是根据主键建立的聚簇索引
  • B+Tree 中每个叶子节点中存放的就是一个完整的数据

7. MySQL 复合索引如何使用

8. 索引的缺点,以及使用注意

  • 缺点
  • 会增加磁盘消耗、
  • 频繁增改索引,反而会影响性能
  • 使用注意
  • 尽量少的创建索引
  • 尽可能使用区分性高的字段建立索引

9. 事务的几个特性

  1. 原子性:成功一起成功,失败一起失败
  2. 一致性:在数据修改前后,必须都是准确的
  3. 隔离性:多个事务不能互相干扰,
  4. 持久性:事务成功提交后,对数据的修改必须永久有效

10. 事务的隔离级别

  • MySQL 默认的隔离级别为:可重复读
  1. 读未提交,导致脏读

    事务A对 ID = 1 的数据进行查询
    事务B对 ID = 1 的数据进行修改
    在事务B提交之前,事务A查询的结果就已经是事务B修改后的数据

  2. 读已提交,解决脏读,导致不可重复读

    事务A对 ID = 1 的数据进行查询
    事务B对 ID = 1 的数据进行修改
    事务B提交前,事务A读到的是原始数据
    事务B提交后,事务A再一次读取,读到的是更新后的数据
    两次读取数据不一致,就是不可重复读

  3. 可重复读,解决不可重复读

    事务A对 ID = 1 的数据进行查询
    事务B对 ID = 1 的数据进行修改
    事务B提交前,事务A读到的是原始数据
    事务B提交后,事务A再一次读取,读到的依旧是原始数据
    多次读取数据都是一致的,就是可重复读

  4. 串行化,解决幻读

    原先表中有一条数据
    事务A读取表中所有数据,此时查出了一条记录
    事务B向表中插入一行记录,并直接提交
    事务A再次读取,此时查出了两条记录
    两次读取数据行数不一致,就是幻读
    串行化,就是在事务 A 未提交时,事务B阻塞

11. MySQL 是如何实现可重复读的

  • 是使用了 多版本并发控制机制,Multi-version concurrent control (MVCC)
  • InnoDB 存储引擎,会在每行数据的最后加上两个隐藏列,
    • 一个是保存创建改行的事务ID
    • 另一个是保存删除改行的事务ID
    • 事务 ID 是 MySQL 自己维护的自增ID
  • 在查询操作时,需要满足以下两个条件
    • 查询创建行的事务ID 小于等于 当前事务ID 的行,这样可以确保这个行是在当前事务或者之前的事务中创建的
    • 查询删除行的事务ID 为空,或者大于当前事务ID 的行,这样可以保证这个行未被删除或者在之后的事务中被删除

12. MySQL 锁有哪些类型

  • 按照对数据操作的类型(读/写)来分
    • 读锁(共享锁):针对同一份数据,多个读操作可以同时进行而不会互相影响
    • 写锁(排他锁):当前写操作没有完成前,他会阻断其他写操作和读操作
  • 按照对数据操作的粒度来分
    • 表锁(主要是MyISAM)
    • 行锁(主要是InnoDB)
      • 在增删改时会加行锁
      • 查的时候一般不会加锁,因为 InnoDB,一般读取的是 MVCC 的快照
    • 页锁

13. 悲观锁和乐观锁是什么?使用场景是什么

  • 悲观锁就是select * from table where id=1 for update,这就是加上了悲观锁,担心自己获取不到这一行的锁,先提前锁上,然后就可以对这一行数据进行其他操作
  • 乐观锁,就是认为自己想要获取锁的时候,就能获取到,不需要提前锁死。在查询数据的时候,除了正常的字段数据,再加上一个版本号,对这一行数据操作完成后,再判断当前库中版本号与之前读取的版本号是否一致,若一致则提交操作,若不一致则重新查询重新操作

14. MySQL 死锁的原理以及如何定位和解决

  • 死锁大致原因

    事务 A 对 ID = 1 的行加上排他锁
    事务 B 对 ID = 2 的行加上排他锁
    然后事务 A 想要请求 ID = 2 的行的锁
    接着事务 B 想要请求 ID = 1 的行的锁
    此时事务 A、B 互相等待

  • 解决:查看死锁日志,根据 SQL 定位对应的代码,排查原因

15. MySQL 调优手段

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

yuan_404

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值