JavaGuide

随看随记

一文搞懂候选码、主码、全码、外码、主属性、主键、主关键字、非主属性清晰总结
数据库三大范式
数据库索引讲的不清晰，看这个视频会好一点
上面视频的文档
什么是回表查询
索引这块可以看看这个UP
数据可见性算法MVCC

数据库基础知识

什么是数据库, 数据库管理系统, 数据库系统, 数据库管理员?

数据库 : 数据库(DataBase 简称 DB)就是信息的集合或者说数据库是由数据库管理系统管理的数据的集合。
数据库管理系统 : 数据库管理系统(Database Management System 简称 DBMS)是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护数据库。
数据库系统 : 数据库系统(Data Base System，简称 DBS)通常由软件、数据库和数据管理员(DBA)组成。
数据库管理员 : 数据库管理员(Database Administrator, 简称 DBA)负责全面管理和控制数据库系统。

什么是元组, 码, 候选码, 主码, 外码, 主属性, 非主属性？

(行)元组：元组（tuple）是关系数据库中的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。在二维表里，元组也称为行。
码 (列)(属性)：码就是能唯一标识实体的属性，对应表中的列。
候选码(能够划分码属性) ：若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何、子集都不能再标识，则称该属性组为候选码。例如：在学生实体中，“学号”是能唯一的区分学生实体的，同时又假设“姓名”、“班级”的属性组合足以区分学生实体，那么{学号}和{姓名，班级}都是候选码。
主码(唯一确定一个记录) : 主码也叫主键。主码是从候选码中选出来的。一个实体集中只能有一个主码，但可以有多个候选码。
外码(关系中的一个属性是另一个表的主键): 外码也叫外键。如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码。
主属性：候选码中出现过的属性称为主属性。比如关系工人（工号，身份证号，姓名，性别，部门）. 显然工号和身份证号都能够唯一标示这个关系，所以都是候选码。工号、身份证号这两个属性就是主属性。如果主码是一个属性组，那么属性组中的属性都是主属性。
非主属性：不包含在任何一个候选码中的属性称为非主属性。比如在关系——学生（学号，姓名，年龄，性别，班级）中，主码是“学号”，那么其他的“姓名”、“年龄”、“性别”、“班级”就都可以称为非主属性。

为什么不推荐使用外键与级联？

对于外键和级联，阿里巴巴开发手册这样说到：

【强制】不得使用外键与级联，一切外键概念必须在应用层解决。

说明: 以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群; 级联更新是强阻塞，存在数据库更新风暴的风险; 外键影响数据库的插入速度
为什么不要用外键呢？大部分人可能会这样回答：
1. 增加了复杂性： a. 每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦, 测试数据极为不方便; b. 外键的主从关系是定的，假如那天需求有变化，数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦。
2. 增加了额外工作：数据库需要增加维护外键的工作，比如当我们做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，保证数据的的一致性和正确性，这样会不得不消耗资源；（个人觉得这个不是不用外键的原因，因为即使你不使用外键，你在应用层面也还是要保证的。所以，我觉得这个影响可以忽略不计。）
3. 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；
4. 对分库分表不友好：因为分库分表下外键是无法生效的。
我个人觉得上面这种回答不是特别的全面，只是说了外键存在的一个常见的问题。实际上，我们知道外键也是有很多好处的，比如：
1. 保证了数据库数据的一致性和完整性；
2. 级联操作方便，减轻了程序代码量；
所以说，不要一股脑的就抛弃了外键这个概念，既然它存在就有它存在的道理，如果系统不涉及分库分表，并发量不是很高的情况还是可以考虑使用外键的

什么是 ER 图？

E-R 图也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。它是描述现实世界关系概念模型的有效方法。是表示概念关系模型的一种方式。
下图是一个学生选课的 ER 图，每个学生可以选若干门课程，同一门课程也可以被若干人选择，所以它们之间的关系是多对多（M: N）。另外，还有其他两种关系是：1 对 1（1:1）、1 对多（1: N）。
我们试着将上面的 ER 图转换成数据库实际的关系模型(实际设计中，我们通常会将任课教师也作为一个实体来处理)：

数据库范式了解吗?

1NF(第一范式)
属性（对应于表中的字段）不能再被分割，也就是这个字段只能是一个值，不能再分为多个其他的字段了。1NF 是所有关系型数据库的最基本要求，也就是说关系型数据库中创建的表一定满足第一范式。
2NF(第二范式)
2NF 在 1NF 的基础之上，消除了非主属性对于码的部分函数依赖。如下图所示，展示了第一范式到第二范式的过渡。第二范式在第一范式的基础上增加了一个列，这个列称为主键，非主属性都依赖于主键。

一些重要的概念：
函数依赖（functional dependency）：若在一张表中，在属性（或属性组）X 的值确定的情况下，必定能确定属性 Y 的值，那么就可以说 Y 函数依赖于 X，写作 X → Y。
部分函数依赖（partial functional dependency）：如果 X→Y，并且存在 X 的一个真子集 X0，使得 X0→Y，则称 Y 对 X 部分函数依赖。比如学生基本信息表 R 中（学号，身份证号，姓名）当然学号属性取值是唯一的，在 R 关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；
完全函数依赖(Full functional dependency) ：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。比如学生基本信息表 R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在 R 关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；
传递函数依赖：在关系模式 R(U)中，设 X，Y，Z 是 U 的不同的属性子集，如果 X 确定 Y、Y 确定 Z，且有 X 不包含 Y，Y 不确定 X，（X∪Y）∩Z=空集合，则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z 子集往往同属于某一个事物，因此可将其合并放到一个表中。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖。。
3NF(第三范式)
3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖。符合 3NF 要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖，所以该表的设计，不符合 3NF 的要求。
总结
1NF：属性不可再分。
2NF(使用单主键，转化成多个表)：1NF 的基础之上，消除了非主属性对于码的部分函数依赖。
3NF(把完全函数依赖的部分再生成一个数据库表)：3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖。

drop、delete 与 truncate 区别？

用法不同
1. drop(丢弃数据): drop table 表名，直接将表都删除掉，在删除表的时候使用。
2. truncate (清空数据) : truncate table 表名，只删除表中的数据，再插入数据的时候自增长 id 又从 1 开始，在清空表中数据的时候使用。
3. delete（删除数据） : delete from 表名 where 列名=值，删除某一列的数据，如果不加 where 子句和truncate table 表名作用类似。
4. truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的数据，但是 truncate 和 delete 只删除数据不删除表的结构(定义)，执行 drop 语句，此表的结构也会删除，也就是执行 drop 之后对应的表不复存在。
属于不同的数据库语言
truncate 和 drop 属于 DDL(数据定义语言)语句，操作立即生效，原数据不放到 rollback segment 中，不能回滚，操作不触发 trigger。而 delete 语句是 DML (数据库操作语言)语句，这个操作会放到 rollback segement 中，事务提交之后才生效。
执行速度不同
一般来说：drop > truncate > delete（这个我没有设计测试过）。
delete命令执行的时候会产生数据库的binlog日志，而日志记录是需要消耗时间的，但是也有个好处方便数据回滚恢复。
truncate命令执行的时候不会产生数据库日志，因此比delete要快。除此之外，还会把表的自增值重置和索引恢复到初始大小等。
drop命令会把表占用的空间全部释放掉。

数据库设计通常分为哪几步?

需求分析 : 分析用户的需求，包括数据、功能和性能需求。
概念结构设计 : 主要采用 E-R 模型进行设计，包括画 E-R 图。
逻辑结构设计 : 通过将 E-R 图转换成表，实现从 E-R 模型到关系模型的转换。
物理结构设计 : 主要是为所设计的数据库选择合适的存储结构和存取路径。
数据库实施 : 包括编程、测试和试运行
数据库的运行和维护 : 系统的运行与数据库的日常维护。

Mysql

MyISAM 和 InnoDB 的区别

是否支持行级锁
MyISAM 只有表级锁(table-level locking)，而 InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。
也就说，MyISAM 一锁就是锁住了整张表，这在并发写的情况下是多么滴憨憨啊！这也是为什么 InnoDB 在并发写的时候，性能更牛皮了！
是否支持事务
MyISAM 不提供事务支持。
InnoDB 提供事务支持，具有提交(commit)和回滚(rollback)事务的能力。
是否支持外键
MyISAM 不支持，而 InnoDB 支持。

面试部分梳理 - 数据库相关推荐
1. 【PHP 面试知识梳理】
  PHP 面试知识梳理算法与数据结构 BTree和B+tree BTree B树是为了磁盘或者其他存储设备而设计的一种多叉平衡查找树,相对于二叉树,B树的每个内节点有多个分支,即多叉. 参考文章:ht ...
2. 2019年秋招 Java 面试知识点梳理（高频问题）
  Java 面试知识点梳理基础一 JVM-内存区域分配 HotSpot 对象创建 JVM-类加载机制 JVM-内存分配(堆上的内存分配) JVM-GC回收机制 JVM-垃圾收集器 JVM指令重排序重 ...
3. 【持续..】WEB前端面试知识梳理 - CSS部分
  传送门: WEB前端面试知识梳理 - CSS部分 WEB前端面试知识梳理 - JS部分最近在看大厂的一些面试题,发现很多问题都是平时没有在意的,很多知识都是知道一点但又很模糊说不出个所以然来,反思自 ...
4. 《Java 后端面试经》数据库篇
  <Java 后端面试经>专栏文章索引: <Java 后端面试经>Java 基础篇 <Java 后端面试经>Java EE 篇 <Java 后端面试经>数 ...
5. 一小时让你Get到面试套路：记一次Java初中级程序员面试流程梳理
  视频教程传送门: 一小时让你Get到面试套路:记一次Java初中级程序员面试流程梳理_哔哩哔哩_bilibili听了N多个师兄师姐的面试录音,采访了N多个师兄时间的面试经历,才总结出来的java面试流 ...
6. 分布式技术高频面试考点梳理
  1:如何准备一线互联网公司面试? 本课时我们来讲讲如何准备一线互联网公司面试. 互联网技术面试的特点互联网公司的技术面试有一些侧重点,国内互联网公司和外企的侧重点又有不同.BAT 互联网公司看重项目 ...
7. 面试归来——梳理社招面试以及浅述对程序员职业生涯的看法
  原谅我是一个后知后觉的人,已经在新的岗位工作了两个月,才写这篇文章. 本文会先讲述博主一个月的面试经历,梳理一下技术面试,浅述关于程序员职业生涯的一些看法. 从创业到再就业大概4个月以前,终止创业已 ...
8. 最全Java面试知识点梳理
  1. 前言最近面试了几家公司,体验了一下电话面试和今年刚火起来的视频面试, 虽然之前就有一些公司会先通过电话面试的形式先评估下候选人的能力水平,但好像不多,至少我以前的面试形式100%都是现场面试. ...
9. mysql 同一张表某个字段更新到另一条数据上_面试基础：数据库MySQL基础入门(下)...
  本文是面试基础的第二篇.本篇偏理论,包括三节: 事务和并发数据库设计索引所选的三个内容均是面试的高频考察点,需要细致地理解 No.1 事务和并发事务:数据库操作的基本单元.对于数据库的 ...
最新文章
热门文章

面试部分梳理 - 数据库

随看随记

数据库基础知识

什么是数据库, 数据库管理系统, 数据库系统, 数据库管理员?

什么是元组, 码, 候选码, 主码, 外码, 主属性, 非主属性？

为什么不推荐使用外键与级联？

什么是 ER 图？

数据库范式了解吗?

drop、delete 与 truncate 区别？

数据库设计通常分为哪几步?

Mysql

MyISAM 和 InnoDB 的区别

面试部分梳理 - 数据库相关推荐

最新文章

热门文章