面试之关系型数据库

目录

• 零、关系型数据库考点
• 1、架构
• 2、索引
  • 索引的数据结构
  • 密集索引和稀疏索引
• 3、锁
• 4、语法
• 参考资料

零、关系型数据库考点

• 架构
• 索引
• 锁
• 语法
• 理论范式

1、架构

面：如何设计一个关系型数据库？

这主要考察咱们对关系型数据库总体架构的把握，至关于让咱们本身编写一个RDBMS（关系型数据库管理系统）。设计架构图以下,能够从下图中的各个模块进行回答。

2、索引

面：为何要使用索引？

答：为了在数据库中记录较多的时候避免每次查询都用全表扫描的方式，咱们须要一种更高效的机制，那就是索引相似与字典中的目录，用来快速查询数据。

面：什么样的信息能成为索引？

答：能将某个记录限定在必定查找范围内的字段，就是一些关键信息，如主键、惟一键以及普通键等。

索引的数据结构

为了提升索引的性能，就要采起一些数据结构来加快索引的查询。索引能够采用的数据结构主要有如下几种：

• 创建二叉查找树进行二分查找
• 创建B-Tree结构进行查找
• 创建B+-Tree结构进行查找
• 创建Hash结构进行查找

二叉查找树的弊端：当对索引的数据结构进行修改后，可能会退化成链表，即时间复杂度从O（logn）下降到O（n）。即便经过旋转等方式使此树可以保证二叉查找树的结构，那么还有一个影响性能的关键因素：I/O读写。深度过深的话，I/O读写次数也会变多，效率仍是很低。因此二叉查找树不适用于创建索引。

B-Tree：经过分析二叉查找树的弊端，咱们能够下降树的高度来减小I/O的次数。那么B-Tree就能够派上用场了。先看下什么是B-Tree，这里的B表示balance（平衡），B-Tree是一种多路自平衡的搜索树。它相似于普通的平衡二叉树，不一样的一点是B-Tree容许每一个节点有更多的子节点。下图是B-Tree的简化图：

B-Tree有如下特色：

• 全部键值分布在整棵树中
• 任何一个关键字出现且只出如今一个节点中
• 搜索有可能在非叶子节点结束
• 在关键字全集内作一次查找，性能逼近二分查找

B+-Tree：B+-Tree是B-Tree的变体，也是一种多路搜索树，它与B-Tree的不一样之处在于：

1. 非叶子节点仅用来索引，数据都保存在叶子节点中
2. 全部叶子节点均有一个链指针指向下一个叶子节点

简化B+-Tree以下图：

面：为何B+-Tree相比B-Tree更适合用来作存储索引？

• B+树的磁盘读写代价更低（内部节点不存储真正数据信息）
• B+树的查询效率更加稳定（全部关键字查询都必须通过根节点到叶子节点，都是O（logn））
• B+树更有利于对数据库的扫描（只需遍历叶子节点，就能够扫描到所有的关键字）

因为B+-Tree的查询必须进过根节点到叶子节点，通过屡次I/O,那么是否可考虑Hash索引呢？

虽然Hash索引的查询效率比B+-Tree索引的查询效率要高，但同时它也有许多的弊端：

• 仅仅能知足“=”，“IN”，不能使用范围查询
• 没法被用来避免数据的排序操做
• 不能利用部分索引键查询
• 不能避免表扫描
• 遇到大量Hash值相等后的状况性能并不必定就会比B+-Tree索引高

因此综上，MySQL采用B+树来做为索引的数据结构。

密集索引和稀疏索引

面：密集索引和稀疏索引的区别

答：

• 密集索引文件中的每一个搜索码都对应一个索引值
• 稀疏索引文件只为搜索码的某些值创建索引项
• 密集索引比稀疏索引更快地定位一条记录
• 稀疏索引所占空间小，而且插入和删除时所需维护的开销也小

在MySQL中的InnoDB中，关于密集索引的知识点以下：

• 若一个主键被定义，则该主键做为密集索引
• 若没有主键被定义，该表的第一个惟一非空索引则做为密集索引
• 若不知足以上条件，InnoDB内部会生成一个隐藏主键（密集索引）

面：如何定位并优化慢查询SQL？（开放性）

答：

1. 根据慢日志定位慢查询SQL
2. 使用explain等工具分析SQL
3. 修改SQL或者尽可能让SQL走索引

实例：首先查看慢日志（DML SQL执行时间大于必定长度）的相关配置。

show VARIABLES like '%query%'

在返回的结果中，关注三个变量：

Variable_name	value
long_query_time	1.000000 #慢查询时间的阈值
slow_query_log	ON #是否开启记录慢查询日志
slow_query_log_file	/home/mysql/data3001/mysql/slow_query.log #慢日志路径

show status like '%slow_queries%' #查看当前慢查询的条数

运行语句SELECT name FROM chapter,chpater表中有50多万条记录，耗时23s。运行上面的查询慢查询条数的SQL语句，会发现增长了1，接下来经过explain工具分析。运行语句explain SELECT name FROM chapter,关注返回结果的type列发现结果是ALL，意味着是走的全表扫描，那么确实是不快的。咱们来看下查询走索引的，explain SELECT id FROM chapter,type列的结果是index，走的是索引（但不是主键索引，看key列结果是fk_chapter_novel，走的是外键索引，说明主键索引不必定比其余索引快）。此时运行SELECT id FROM chapte只耗时2.9秒。来强制走下主键索引，运行语句SELECT id FROM chapter FORCE INDEX(PRIMARY),耗时23s，运行EXPLAIN SELECT id FROM chapter FORCE INDEX(PRIMARY)发现是走了主键索引的，可是耗时却和全表扫描差很少了。

面：索引是创建的越多越好吗？

答：答案固然是否认的。

• 数据量小的表不须要创建索引，创建会增长额外的索引开销
• 数据变动须要维护索引，所以更多的索引意味着更多的维护成本

3、锁

关于数据库锁部分主要回答以下问题：

• MyISAM与InnoDB关于锁方面的区别是什么
• 数据库事务的四大特性
• 事务隔离级别以及各级别下的并发访问问题
• InnoDB可重复读隔离级别下如何避免幻读
• RC（提交读）、RR（可重复读）级别下的InnoDB的非阻塞如何实现

面：MyISAM与InnoDB关于锁方面的区别是什么？

答：

• MyISAM默认使用的是表级锁，不支持行级锁
• InnoDB默认使用的是行级锁，也支持表级锁

共享锁和排它锁的兼容性

-	X	S
X	冲突	冲突
S	冲突	兼容

MyISAM适合的场景

• 频繁执行全表count语句
• 对数据进行增删改的频率不高（表级锁，每次都会锁住整张表），查询很是频繁
• 没有事务

InnoDB适合的场景

• 数据增删改查都至关频繁（行级锁）
• 可靠性要求比较高，要求支持事务

数据库锁的分类

• 按锁的粒度划分，可分为表级锁、行级锁、页级锁
• 按锁级别划分，可分为共享锁、排它锁
• 按加锁方式，可分为自动锁、显式锁
• 按操做划分，可分为DML锁、DDL锁
• 按使用方式划分，可分为乐观锁、悲观锁

面：数据库事务的四大特性

答：ACID

1. 原子性（Atomic）：事务中的全部操做要么所有执行，要么所有失败回滚
2. 一致性（Consistency）：确保数据库的状态从一个一致性状态转变为另外一个一致性状态，一致性状态是指数据库中的数据应知足完整性约束
3. 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不该该影响其余事务的执行
4. 持久性（Durability）：一个事务提交后，它对数据库的修改应该永久保存在数据库中

面：能说说事务隔离级别以及各级别下的并发访问问题吗？

答：MySQL事务的隔离级别由低到高分别是read uncommitted（未提交读）、read committed（提交读）、repeatable read（可重复读）、serializable（串行化）。并发访问问题及对应解决的事务隔离级别以下：

• 更新丢失（一个事务的更新覆盖掉了另外一个事务的更新）：MySQL中全部事务隔离级别在数据库层面上都可避免

  实例以下图：

• 脏读（一个事务读到另一个未提交事务的数据）：READ-COMMITTED事务隔离级别及以上可避免

• 不可重复读（事务A屡次读取同一数据，事务B在事务A读取的同时对该数据作了更新并提交，致使事务A屡次读取到的结果不一致）：REPEATABLE-READ事务隔离级别及以上可避免

• 幻读（事务A屡次读取与搜索条件相匹配的若干行，事务B用插入或删除行的方式来修改事务A的结果集，致使事务A出现了“幻觉”）：SERIALIZABLE事务隔离级别可避免

当前读与快照读

当前读的数据是最新的，而快照读读取的是快照。当前读主要是如下SQL：

select...lock in share mode
select...for update
update,delete,insert

面：能说说InnoDB可重复读隔离级别下如何避免幻读吗？

答：表面上来看是经过伪MVCC的快照读（非阻塞读）实现的，但本质确实经过next-key锁即行锁+gap锁实现的。

4、语法

SELECT 
    column_1, column_2, ...
FROM
    table_1
[INNER | LEFT |RIGHT] JOIN table_2 ON conditions
WHERE
    conditions
GROUP BY column_1
HAVING group_conditions
ORDER BY column_1
LIMIT offset, length;

参考资料

慕课网 剑指Java面试-Offer直通车

由 B-/B+树看 MySQL索引结构

稠密索引与稀疏索引