秋招面试知识点----数据库篇

B树

B树相对于平衡二叉树的不同是，每个节点包含的关键字增多了，特别是在B树应用到数据库中的时候，数据库充分利用了磁盘块的原理就是局部i性的思想，装入部分就可以执行，
在B树的基础上每个节点存储的关键字数更多，树的层级更少所以查询数据更快，所有指关键字指针都存在叶子节点，所以每次查找的次数都相同所以查询速度更稳定;

mysql B+

1）B+跟B树不同B+树的非叶子节点不保存关键字记录的指针，只进行数据索引，这样使得B+树每个非叶子节点所能保存的关键字大大增加；

（2）B+树叶子节点保存了父节点的所有关键字记录的指针，所有数据地址必须要到叶子节点才能获取到。所以每次数据查询的次数都一样，比较稳定；

（3）B+树叶子节点的关键字从小到大有序排列，左边结尾数据都会保存右边节点开始数据的指针。

（4）非叶子节点的子节点数=关键字数（虽然他们数据排列结构不一样，但其原理还是一样的Mysql 的B+树是用第一种方式实现）;

为啥用B+B+

1.文件很大，不可能全部存储在内存中，故要存储到磁盘上，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数（为什么使用B-/+Tree，还跟磁盘存取原理有关。）

3.局部性原理与磁盘预读，预读的长度一般为页（page）的整倍数，（在许多操作系统中，页得大小通常为4k）

4.数据库系统巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入，(由于节点中有两个数组，所以地址连续)。而红黑树这种结构，而红黑树这种结构，h明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的I/O渐进复杂度也为O（h），效率明显比B-Tree差很多。

1.Hash索引仅仅能满足“=”，“IN”，不能支持范围查询

2.对于排序操作Hash索引也满足不了

3.Hash索引不能避免表扫描

4.当有大量数据的Hash值相等的时候Hash索引的性能大打折扣***h*明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性

索引

普通索引，唯一索引，主键索引

第一种方式 :

  CREATE INDEX account_Index ON `award`(`account`);

第二种方式:

ALTER TABLE award ADD INDEX account_Index(`account`)

全文索引

文本字段上(text)如果建立的是普通索引,那么只有对文本的字段内容前面的字符进行索引,其字符大小根据索引建立索引时申明的大小来规定.

如果文本中出现多个一样的字符,而且需要查找的话,那么其条件只能是 where column lick ‘%xxxx%’ 这样做会让索引失效

.这个时候全文索引就祈祷了作用了

ALTER TABLE tablename ADD FULLTEXT(column1, column2)

有了全文索引，就可以用SELECT查询命令去检索那些包含着一个或多个给定单词的数据记录了。

在经常需要搜索的列上**

• 主键列上可以确保列的唯一性
• 在表与表的而连接条件上加上索引,可以加快连接查询的速度
• 在经常需要排序(order by),分组(group by)和的 distinct 列上加索引可以加快排序查询

哪些情况不适合创建索引？
1.查询中很少使用到的列
2.很少数据的列，男女重复性太高
3.定义为 text 和 image 和 bit 数据类型的列
4.表的修改大大多于查询

哪些情况会造成索引失效？

• 如果条件中有 or，即使其中有条件带索引也不会使用(这也是为什么要少用 or 的原因)

• 索引字段的值不能有 null 值

• like 查询以%开头，字串类型的字段索引按首字母开头构成一个tree，

• 在索引列上做计算，c+=100不行

• 函数

• 类型转换等）

• 负面操作，比如is not, not in, !=, <>, is not null,都用不上索引

慢sql

一个 SQL 执行的很慢，我们要分两种情况讨论：

1、偶尔很慢**，则有如下原因

(1)、数据库在刷新脏页，例如 redo log 写满了需要同步到磁盘。

(2)、执行的时候，遇到锁，如表锁、行锁。

2、一直执行的很慢，则有如下原因。

(1)、没有用上索引：例如该字段没有索引；由于对字段进行运算、函数操作导致无法用索引。

(2)、数据库选错了索引。

explain

# 建索引 create index idx on emp(age, deptId, name);

• **id：**就是数值越大越先执行，
• select_type:
  • simple，表示此查询不包含union查询或者子查询，简单粗暴
  • primary，表示此查询是最外层的查询，就是父级
  • union，表示此查询是union的第二或者随后的查询
• table:数据是哪张表的
• type：
  • system:表仅有一行(=系统表)。这是const联接类型的一个特例，想屁吃。
  • const:表最多有一个匹配行,它将在查询开始时被读取。因为仅有一行,在这行的列值可被优化器剩余部分认为是常数。const表很快,因为它们只读取一次!例如，name=“张三”
  • eq_ref:对于每个来自于前面的表的行组合,从该表中读取一行。这可能是最好的联接类型,除了const类型，做到这，用到了索引，还只有一条数据。
  • ref:对于每个来自于前面的表的行组合,所有有匹配索引值的行将从这张表中读取，就是也用了索引，就是结果的元组多个。
  • ALL：对于每个来自于先前的表的行组合,进行完整的表扫描
• possible_keys：理论使用
• key：实际使用
• keylen：就是用了多少索引
• rows：就是搜多少找到的
• extra：
  • Using filesort ：说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成的排序操作称为“文件排序”，这一般是需要优化的。
  • Using temporary ：使了用临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。这一般是需要优化的。
  • USING index：表示相应的select操作中使用了覆盖索引(Covering Index)，避免访问了表的数据行，效率不错。如果同时出现using where，表明索引被用来执行索引键值的查找;如果没有同时出现using where，表明索引只是用来读取数据而非利用索引执行查找，一般就是没有where。

sql执行

连接器： 身份认证和权限相关(登录 MySQL 的时候)。

•查询缓存: 执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。

•分析器: 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。

•优化器： 按照 MySQL 认为最优的方案去执行。

•执行器: 执行语句，然后从存储引擎返回数据。

SQL 等执行过程分为两类，

一类对于查询等过程如下：权限校验—》查询缓存—》分析器—》优化器—》权限校验—》执行器—》引擎

•对于更新等语句执行流程如下：分析器----》权限校验----》执行器—》引擎—redo log prepare—》binlog—》redo log commit

MVCC多版本并发控制

就是多版本并发控制，解决数据库并发的问题，事务的实现主要体现在读已提交，可重复读，他有一个版本连的东西，就是表里面有两个隐藏的列，一个是事务id，一个是上一个版本的位置，方便回退；

​ 就是进行修改时，老版本写到undo日志，undo日志中有版本链

readview：

读已提交和重复读就是readview策略不同，就是一个列表有着事务id，是那些开始的食物但是还没提交的

例子：a=100，没提交，我去查是查不到的，readview里面有100；两种的策略都查不到，但是现在提交了，有新开一个事务a=200；

读已提交就是会更新readview，表里的100没了可以读到a=100

可重复读就是不更新readview，所以独到的是a=100之前的数；

Redis五种数据类型

Redis对于过期键有三种清除策略：

• 被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期key
• 主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key
• 当前已用内存超过maxmemory限定时，触发主动清理策略

redis持久化

rdb

Redis会单独fork一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程 都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。 这就很高性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性无所谓，那 RDB方式要比AOF方式更加的高效。RDB的缺点是后一次持久化后的数据可能丢失。我们默认的就是 RDB，一般情况下不需要修改这个配置！会有sava 9 100，就是fork进程消耗资源，60秒以保存，可能会丢东西

aof

将我们的所有命令都记录下来，history，恢复的时候就把这个文件全部在执行一遍！

appendfsync always 每次修改都会 sync。消耗性能

appendfsync everysec 每秒执行一次 sync，可能会丢失这1s的数据！

appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度快

RDB与AOF的选择

• RDB与AOF的选择世界上是在做一种权衡，每种都有利弊

• 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF

• 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，先用RDB

• 灾难恢复选用RDB

• 双保险策略：同时开启RDB与AOF，重启后，Redis优先选择使用AOF来恢复速度，降低丢失数据的量分布式锁

  分布式锁：当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。

  eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。

分布式锁

加锁

最简单的方法是使用 setnx 命令。key 是锁的唯一标识，按业务来决定命名。比如想要给一种商品的秒杀活动加锁，可以给 key 命名为 “lock_sale_商品ID” 。而 value 设置成什么呢？我们可以姑且设置成 1。加锁的伪代码如下：

setnx（lock_sale_商品ID，1）

当一个线程执行 setnx 返回 1，说明 key 原本不存在，该线程成功得到了锁；当一个线程执行 setnx 返回 0，说明 key 已经存在，该线程抢锁失败。

解锁

有加锁就得有解锁。当得到锁的线程执行完任务，需要释放锁，以便其他线程可以进入。释放锁的最简单方式是执行 del 指令，伪代码如下：

del（lock_sale_商品ID）

释放锁之后，其他线程就可以继续执行 setnx 命令来获得锁。

锁超时

锁超时是什么意思呢？如果一个得到锁的线程在执行任务的过程中挂掉，来不及显式地释放锁，这块资源将会永远被锁住（死锁），别的线程再也别想进来。所以，setnx 的 key 必须设置一个超时时间，以保证即使没有被显式释放，这把锁也要在一定时间后自动释放。setnx 不支持超时参数，所以需要额外的指令，伪代码如下：

expire（lock_sale_商品ID， 30）

三种弊端

1. setnx和expire` 的非原子性

设想一个极端场景，当某线程执行 setnx，成功得到了锁：

setnx 刚执行成功，还未来得及执行 expire 指令，节点 1 挂掉了。

这样一来，这把锁就没有设置过期时间，变成死锁，别的线程再也无法获得锁了。

怎么解决呢？setnx 指令本身是不支持传入超时时间的，set 指令增加了可选参数，伪代码如下：

set（lock_sale_商品ID，1，30，NX）

这样就可以取代 setnx 指令。

2. del` 导致误删

又是一个极端场景，假如某线程成功得到了锁，并且设置的超时时间是 30 秒。

如果某些原因导致线程 A 执行的很慢很慢，过了 30 秒都没执行完，这时候锁过期自动释放，线程 B 得到了锁。

随后，线程 A 执行完了任务，线程 A 接着执行 del 指令来释放锁。但这时候线程 B 还没执行完，线程A实际上 删除的是线程 B 加的锁。

**怎么避免这种情况呢？**可以在 del 释放锁之前做一个判断，验证当前的锁是不是自己加的锁。至于具体的实现，可以在加锁的时候把当前的线程 ID 当做 value，并在删除之前验证 key 对应的 value 是不是自己线程的 ID。

加锁：

String threadId = Thread.currentThread().getId()
set（key，threadId ，30，NX）

解锁：

if（threadId .equals(redisClient.get(key))）{
    del(key)
}

但是，这样做又隐含了一个新的问题，判断和释放锁是两个独立操作，不是原子性。

3. 出现并发的可能性

还是刚才第二点所描述的场景，虽然我们避免了线程 A 误删掉 key 的情况，但是同一时间有 A，B 两个线程在访问代码块，仍然是不完美的。怎么办呢？我们可以让获得锁的线程开启一个守护线程，用来给快要过期的锁“续航”。

当过去了 29 秒，线程 A 还没执行完，这时候守护线程会执行 expire 指令，为这把锁“续命”20 秒。守护线程从第 29 秒开始执行，每 20 秒执行一次。

当线程 A 执行完任务，会显式关掉守护线程。

另一种情况，如果节点 1 忽然断电，由于线程 A 和守护线程在同一个进程，守护线程也会停下。这把锁到了超时的时候，没人给它续命，也就自动释放了。

redis主库和从库不一致

主从同步有时延，这个时延期间读从库，可能读到不一致的数据。

例如a在读取，b改了，同步的时候，a的从机收不到；

（1）业务可以接受，系统不优化

（2）强制读主，高可用主库，用缓存提高读性能

（3）在cache里记录哪些记录发生过写请求，来路由读主还是读从

雪崩解决

redis高可用 这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续 工作，其实就是搭建的集群。（异地多活！）
限流降级
这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对 某个key只允许一个线程查询数据和写缓存，其他线程等待。
数据预热
数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数 据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让 缓存失效的时间点尽量均匀