数据库

基本概念

实体

主键

主键应当是唯一的，并且几乎不会变动码：所有属性都依赖于码属性。

关键字

码 : 能够唯一标识一条记录的属性或属性集。 候选码 : 能够唯一标识一条记录的最小属性集 主键 : 人为从候选码中挑的一个码。 主属性 : 包含在任一候选码中的属性称主属性 非主属性 : 不包含在候选码中的属性称为非主属性

数据库范式

范式是一种规范，能够减少数据冗余。但是范式不是越高越好，因为高的范式容易导致数据库性能的下降（查询插入缓慢）

第一范式

所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。

第二范式

第二范式首先要满足第一范式。第二范式是指每条记录都要有唯一的标识

依赖有三种

完全函数依赖。 y 完全依赖于 x 表示，不存在一个 x 对应两个 y 的情况，而且任何一个 x 的真子集 x’，y 未必依赖于 x’
部分函数依赖。y 依赖 x 但是不完全依赖 x
传递函数依赖。x->y->z 则称 z 传递依赖于 x

准确地说是：所有非主属性不能部分依赖于主码。比如如果一个表，主键是（学号，课程）学号|课程|姓名 | 分数| —–|—–|—–|—–| 分数是满足的，因为分数完全依赖于（学号，课程）, 但是姓名是部分依赖于（学号，课程）的。

第三范式

第三范式 (3NF) 要求一个关系中不包含已在其它关系已包含的非主关键字信息。准确地说是，不能有属性传递依赖于主键。比如下表的主键是学号。学号|系名|姓名 | 系主任名| —–|—–|—–|—–| 系主任名是传递依赖于学号的。因为学号->系名->系主任名所以正确的做法是将系名和系主任名分开存到另一个表里，来减少数据冗余。

巴斯-科德范式 (BCNF)

在 3NF 的基础上，没有任何属性完全函数依赖于非候选码的任何一组属性。也就是主键不会被非主属性绑定（比如仓库只有一个管理员，管理员也只管一个仓库，那么如果仓库是主键，就不能

事务 TRANSACTION

将两个单词 (trans action) 分开念即可

事务-廖雪峰

ACID

A：Atomic , 原子性，将所有 SQL 作为原子工作单元执行，要么全部执行，要么全部不执行； C：Consistent , 一致性，事务完成后，所有数据的状态都是一致的，即 A 账户只要减去了 100, B 账户则必定加上了 100; 如果数据库在执行前是一致的，那么它在执行后也应当是一致的。而数据库自身的一致性是指其是否能正确反映客观世界。 I：Isolation , 隔离性，如果有多个事务并发执行，每个事务作出的修改必须与其他事务隔离； D：Duration , 持久性，即事务完成后，对数据库数据的修改被持久化存储。即使系统在此事务执行后崩溃了。

四种隔离级别

未提交读 (read uncommitted)

允许读取未提交数据，可能发生脏读

已提交读 (consistent read)

大多数数据库的默认等级只允许读取已经提交的数据，但不要求可重复读，在事务两次读取一个数据之间，另一个事务更新了数据并提交。

可重复读 (repeatable read)

Mysql 的默认等级只允许读取已提交数据，而且在一个事务两次读取一个数据项期间，其他事务不得更新该数据。但该事务不要求与其他事务可串行化。可能发生幻读：一个事务（同一个 read view) 在前后两次查询同一范围的时候，后一次查询看到了前一次查询没有看到的行。重点在于新增的行。

串行化 (serializable read)

对同一行记录，读会加”读锁”, 写会加”写锁”, 当出现读写冲突时，前后访问的事务必须等前一个事务执行完成，才能继续执行。

元数据

元数据（英语：metadata), 又称诠释资料、中介资料、中继资料、后设资料等，为描述其他资料信息的资料。有三种不同类型的元数据，分别是记叙性元数据、结构性元数据和管理性元数据。

记叙性元数据描述了用于发现与辨别意义的资源。它可以包括如标题、摘要、作者和关键字等元素。
结构性元数据是有关于资料容器的元数据，指示如何整理其中复合的对象。例如页面依什么排序方式组成章节。
管理性元数据是用于管理资源的信息，例如资料产生的时间和方式、文件种类和其它技术信息，以及谁有权限访问它。在某些国家，有关于电子邮件、电话、网页、IP 链接与手机位置的元数据是固定由国家来存储的。

文件系统和数据库的区别

文件系统把数据组织成相互独立的数据文件，实现了记录内的结构性，但整体无结构；
数据库系统实现整体数据的结构化（也就是建立表与表之间的联系）, 这是数据库的主要特征之一，也是数据库系统与文件系统的本质区别。
在文件系统中，数据冗余度大，浪费存储空间，容易造成数据的不一致；
数据库系统中，数据是面向整个系统，数据可以被多个用户、多个应用共享使用，减少了数据冗余。
文件系统中的文件是为某一特定应用服务的，当要修改数据的逻辑结构时，必须修改应用程序，修改文件结构的定义，数据和程序之间缺乏独立性；
数据库系统中，通过 DBMS 的两级映象实现了数据的物理独立性和逻辑独立性，把数据的定义从程序中分离出去，减少了应用程序的维护和修改。
一般来说数据库系统会调用文件系统来管理自己的数据文件，但也有些数据库系统能够自己管理数据文件，甚至在裸设备上。文件系统是操作系统必须的，而数据库系统只是数据库管理和应用所必需的。

数据模型及其地位

数据模型是对现实世界数据特征的抽象，其三要素是 ( 数据结构 , 数据操作 , 数据的约束条件 ) 最常用的数据模型分为概念数据模型和基本数据模型概念数据模型是按用户的观点对数据和信息建模，是现实世界到信息世界的第一层抽象。基本数据模型是按计算机系统的观点对数据建模，是现实世界数据特征的抽象，用于 dbms 的实现（层次模型，网状模型，关系模型）

索引

MySQL 支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此 MySQL 数据库支持多种索引类型，如 BTree 索引，哈希索引，全文索引等等在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。（也就是说索引就是一种加速查找的数据结构）

索引的不足

虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行 INSERT、UPDATE 和 DELETE. 因为更新表时，MySQL 不仅要保存数据，还要保存一下索引文件
建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。

聚集索引和非聚集索引

聚集索引是指数据库表行中数据的物理顺序与键值的逻辑（索引）顺序相同（准确的说是连续存放）. 一个表只能有一个聚集索引, 因为一个表的物理顺序只有一种情况。与非聚集索引相比，聚集索引有着更快的检索速度。

稠密索引和非稠密索引

索引项指每个搜索码值都有一个对应的索引。稠密索引可支持聚集和非聚集索引。对于聚集索引，稠密索引是索引项包括搜索码值和指向对应的第一条数据记录的指针。对于非聚集索引，索引必须包括搜索码值和指向所有具有相同搜索码值的记录的指针列表。稀疏索引就只能支持聚集索引。形式和稠密索引对聚集索引的形式一样。稀疏索引只为搜索码的某些值建立索引项。每个索引项包括一个搜索码值和指向具有该搜索码值的第一条数据记录的指针。

视图

视图是为了不让用户完全看到逻辑模型，或者是想要建立一个更符合用户直觉的而采用的一种关系集合。
视图一般是作为虚关系存在，针对视图的查询，往往需要先计算出集合，然后再进行查询。也有很少数的情况，面对大量的查询，有些数据库将视图物化。
视图一般不会允许进行更改。

崩溃后的恢复

数据库有日志系统。对于已经提交的事务，则一定能保证其持久性。如果执行到一半的事务，就回滚事务。

主键

主键是为了作为表的唯一标识的候选关键字，可以由一个字段构成，也可以由多个字段组成。主键应该对于用户无意义，也不应该被更新。

死锁

数据库的死锁和操作系统基本一致，操作系统的是进程之间对于资源的争夺，数据库的死锁是事务之间关于读写的锁。

死锁的四个必要条件

互斥访问
请求保持
不剥夺
环路等待

尽可能避免死锁

保持事务简短
使用较低的隔离等级
尽量避免用户交互

MYSQL

引擎

MySQL 主要有四种引擎，MyISAM, InnoDB（默认引擎）, MEMORY, Archive.

MyISAM 更注重性能，平台的迁移性更好。不支持事务的设计，如果有需求可以在 service 层进行根据自己的业务需求进行相应的控制。
InnoDB 支持事务和外部键等复杂操作。
MEMORY 将数据存在内存中，一般是用来存储临时数据。
Archive 主要用于存储日志等文件。

关于索引以及 b+树的实现

MyISAM 索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。
在 InnoDB 中，表数据文件本身就是按 B+Tree 组织的一个索引结构，这棵树的叶节点 data 域保存了完整的数据记录。这个索引的 key 是数据表的主键，因此 InnoDB 表数据文件本身就是主索引。

MVCC

MVCC 全称为多版本并发控制。主要在 InnoDB 中用以实现读已提交和可重复读。实现原理如下：对于每行数据，都增加两个隐藏列，一个是创建时间（版本号）, 一个是删除时间（版本号）. 然后对于每个事务都有其对应的唯一的 ID, 事务创建一个记录时，会将自身的 ID 填入创建时间。事务删除一个记录时，将 ID 填入删除时间。更新采取先删后建的方式。对于查询来说，一个事务尽可能查询到同时满足以下条件的记录：

删除时间大于当前的版本号。也就是它被后面的事务删除或更新。
创建时间小于等于当前的版本号，也就是在事务执行前就已经存在的数据或者是本事务添加的数据。具体原理比较复杂，日后再说。 CSDN-【MySQL 笔记】正确的理解 MySQL 的 MVCC 及实现原理

b 树

B 树的优点在于数据存储在每个结点中，可以更快访问到，而不必须走到叶子结点，B 树更多的用在文件系统中。

根节点至少两个子节点，其他节点最多有 m-1 个关键字 (m 个子树）, 最少有 floor(m/2)-1 个节点 (floor(m/2) 个子树）.
每个节点可以存储数据.
每个节点的左儿子都严格小于它本身，右儿子都严格大于它本身。

b+树

b+树是在 b 树的基础上改进的。

相对于 b 树的不同

每个节点最多有 m 个关键字，每个关键字对应一颗子树。
数据全部存在叶子节点，非叶子节点不存数据。
父节点的元素也一定存在在某个子节点之中, 父节点的元素也是子节点元素的最大值的集合。
最后的叶子节点由一个链表穿起，从小到大，便于范围查询

相对于 b 树的优点

范围查询更加方便。b 树在找到下界之后需要中序遍历，io 次数多。b+树查询到下界之后可以通过链表来遍历。减少了 io 次数。
b+树节点中不含数据, 所以占用同样大小的磁盘空间的情况下，可以更多的存储节点。且查询效率比 b 树稳定，因为一定会查询到叶子节点。

数据字典

在开发的程序（系统）中的数据字典。可以帮助开发人员理解各个数据项目的类型、数值和它们与现实世界中的对象的关系。

数据库