数据库

1. 主键 超键 候选键 外键

主键：表中的一个或多个字段，唯一地标识表中某一条记录；一个表只有一个主键，不允许为null
超键：表中唯一标识元组的属性集，一个属性可以是一个超键，多个属性也是
候选键：不含有多余属性的超键，若再删除属性，则不是键
外键：在一个表中存另一个表的主键

2.数据库事务的四个特性及含义

事务是数据库中一个单独的执行单元，通常由高级数据库操作语言或者编程语言写的用户程序的执行所引起。更改数据成功，事务中更改的数据会提交，不再改变，否则取消或回滚，更改无效。
ACID atomicity、correspondence、isolation、durability
原子性：事务要么全部完成、要么全部不完成；执行过程发生错误，则回滚到事务之前状态，就像没执行过
一致性：数据库的完整约束不被破坏
隔离性：给定时间执行唯一操作，这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。
持久性：事务完成之后，事务所做的更改持久保存在数据库中，不会被回滚

数据库四种隔离级别

不提交的读、提交的读、可重复的读和串行化

3.视图的作用，视图可以更改么？

视图：是从一个或多个表导出的虚拟的表，其内容由查询定义。具有普通表的结构，但是不实现数据存储。视图是动态的数据的集合，数据是随着基表的更新而更新。
创建视图：create view XXX as XXXXXXXXXXXXXX;
对视图的修改：要将视图转化为基本表，再对基本表修改
单表视图一般用于查询和修改，会改变基本表的数据，
多表视图一般用于查询，不会改变基本表的数据。可能不可修改，因为修改是对基本表的修改
作用：
①简化了操作，把经常使用的数据定义为视图。
②安全性，用户只能查询和修改能看到的数据。
③逻辑上的独立性，屏蔽了真实表的结构带来的影响。

视图可以使应用程序和数据库表在一定程度上独立。如果没有视图，应用一定是建立在表上的。有了视图之后，程序可以建立在视图之上，从而程序与数据库表被视图分割开来。

缺点:
①性能差
数据库必须把视图查询转化成对基本表的查询，如果这个视图是由一个复杂的多表查询所定义，那么，即使是视图的一个简单查询，数据库也要把它变成一个复杂的结合体，需要花费一定的时间。
②修改限制
当用户试图修改视图的某些信息时，数据库必须把它转化为对基本表的某些信息的修改，对于简单的视图来说，这是很方便的，但是，对于比较复杂的试图，可能是不可修改的。

4.drop,delete与truncate的区别

drop:删除整个表，包括数据和结构
delete：删除表中数据，一条一条记录，可以与where连用
truncate：删除表中全部数据，再插入时自增长id又从1开始
（1）delete每次删除一行数据，并将删除操作作为事务记录保存在日志中，以便进行回滚；truncate一次删除所有，不保存不可回滚，并且不会激活有关删除触发器，速度快；
（2）表和索引所占空间。truncate恢复到初始大小，delete不会减少，drop释放
（3）应用范围。truncate只对table；delete对table和view
（4）truncate和delete只删数据；drop删除数据和结构
（5）delete为DML（data maintain Language),这个操作会被放到 rollback segment中,事务提交后才生效。可以回滚；truncate和drop为DLL（data define language),操作立即生效，原数据不放到 rollback segment中，不能回滚，一触即发
（6） 对于由 FOREIGN KEY 约束引用的表，不能使用 TRUNCATE TABLE，而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中，所以它不能激活触发器。
（7） Truncate table 表名 速度快,而且效率高,因为:
truncate table 在功能上与不带 WHERE 子句的 DELETE 语句相同：二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少。DELETE 语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。
（8） TRUNCATE TABLE 删除表中的所有行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值，请改用 DELETE。如果要删除表定义及其数据，请使用 DROP TABLE 语句。

索引的工作原理及其种类

索引是与表或视图关联的磁盘上结构。对表中列值排序的一种结构。
数据库索引，是数据库管理系统中一个排序的数据结构，这些数据结构以某种方式引用（指向）数据,以协助快速查询、更新数据库表中数据。这种数据结构，就是索引。索引的实现通常使用B树及其变种B+树。
从数据结构角度
1、B+树索引(O(log(n)))：关于B+树索引
2、hash索引：
a 仅仅能满足"=",“IN"和”<=>"查询，不能使用范围查询
b 其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引
c 只有Memory存储引擎显示支持hash索引
3、FULLTEXT索引（现在MyISAM和InnoDB引擎都支持了）
4、R-Tree索引（用于对GIS数据类型创建SPATIAL索引）
从物理存储角度
1、聚集索引（clustered index）
2、非聚集索引（non-clustered index）
从逻辑角度
1、主键索引：主键索引是一种特殊的唯一索引，不允许有空值
2、普通索引或者单列索引
3、多列索引（复合索引）：复合索引指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用复合索引时遵循最左前缀集合
4、唯一索引或者非唯一索引
5、空间索引：空间索引是对空间数据类型的字段建立的索引，MYSQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING、POLYGON。MYSQL使用SPATIAL关键字进行扩展，使得能够用于创建正规索引类型的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL，空间索引只能在存储引擎为MYISAM的表中创建

数据库B+树索引

B/B+树是为了磁盘或其它存储设备而设计的一种平衡多路查找树。
B+树的磁盘读写代价更低：B+树的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对B树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。

2、B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

3、由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。

B+树的特点
B树和B+树的区别在哪呢？

B+跟B树不同B+树的非叶子节点不保存键值对应的数据，这样使得B+树每个节点所能保存的键值大大增加；

B+树叶子节点保存了父节点的所有键值和键值对应的数据，每个叶子节点的键值从小到大链接；

B+树的根节点键值数量和其子节点个数相等;

B+的非叶子节点只进行数据索引，不会存实际的键值对应的数据，所有数据必须要到叶子节点才能获取到，所以每次数据查询的次数都一样

B-树：多路搜索树，每个结点存储M/2到M个关键字，非叶子结点存储指向关键字范围的子结点；所有关键字在整颗树中出现，且只出现一次，非叶子结点可以命中；
B+树：在B-树基础上，为叶子结点增加链表指针，所有关键字都在叶子结点中出现，非叶子结点作为叶子结点的索引；B+树总是到叶子结点才命中；

简述Mysql几种Join的区别

一、外连接
1、笛卡尔积
两表关联，把左表的列和右表的列通过笛卡尔积的形式表达出来。Join
二、内连接
2、左连接
两表关联，左表全部保留，右表关联不上用null表示。Left join
3、右连接
右表全部保留，左表关联不上的用null表示。Right join
4、内连接
两表关联，保留两表中交集的记录。Inner join
三、全连接
5、全连接
两表关联，查询它们的所有记录。
oracle里面有full join,但是在mysql中没有full join。我们可以使用union来达到目的。
-> select * from t1 left join t2 on t1.id = t2.id
-> union
-> select * from t1 right join t2 on t1.id = t2.id;
6、并集去交集
两表关联，取并集然后去交集。
-> select * from t1 left join t2 on t1.id = t2.id where t2.id is null
-> union
-> select * from t1 right join t2 on t1.id = t2.id where t1.id is null;

内连接和外连接

内连接称为自然连接，只有两个表相匹配的行才能在结果中出现
外连接除了符合连接条件的，还有表中单独的数据

数据库范式

减少数据库的数据冗余，增加数据的一致性。
1 第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。
2 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。
3 第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。（我的理解是消除表中相同属性冗余）<