属性： 把数据库中的一个表类比成一个公司，那么公司里的每个人都是一个“属性”（表中的一个字段视为一个属性），不管老板还是员工，只要是公司里的人，就都是一个属性。
主键： 老板就是“主键”，所有普通员工都得听他的（主键可以唯一地标识属性元组）。但是，老板未必是一个人，可能在法律上我和我兄弟同时是公司的老板（主键可能是多个属性的组合）。要指挥员工，需要我们俩一起指挥才行（主键中所有属性的组合才能唯一地标识属性元组）。
候选键： 公司不是独裁制的，老板这个位置有很多候选人，他们都有能力指挥所有普通员工（候选键都可以唯一标识属性元组），这些候选人就是“候选键”，但是所有候选人里只能选出一个做老板（主键是一个被选中的候选键），老板是特殊的候选人。当然，候选人可能也其实是几个人的组合，比如另外几个兄弟的组合，但他们也得一起行动才有能力指挥员工（候选键中所有属性的组合才能唯一地标识属性元组）。
超键： 有候选人（包括老板）的一堆人就是“超键”（能唯⼀标识元组的属性集）。当然这堆人也可以只包含候选人或老板，这样也叫“超键”。
主属性： 是候选人或老板的人（或是候选人组合中的一个）就是“主属性”（候选键中的属性称为主属性）。
非主属性： 不是候选人或老板的人（也不在任何候选人组合中）就是“非主属性”（不属于任何候选码的属性称为非主属性）。
外键： 公司里某个人（或某几个人的组合）是另一个公司的老板，那他或他们就是“外键”（一个表中存在的另一个表的主键称为此表的外键）。
-
*一二三范式★★★★★
第一范式 (1NF)
属性不可分。即数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体
中的某个属性不能有多个值或者不能有重复的属性。（最基本）
每个字段都是原子性的，即不可再分的。
第二范式 (2NF)
每个非主属性完全函数依赖于键码。可以通过分解来满足 2NF。
消除部分依赖
在满足1NF的前提下，表中不存在部分依赖，非主键列要完全依赖于主键。(主要是说在联合主键的情况下，非主键列不能只依赖于主键的一部分)
第三范式 (3NF)
非主属性不传递函数依赖于键码。简而言之，第三范式就是属性不依赖于其它非主属性。
消除传递依赖
第三范式是在满足第二范式的基础上，消除非主键字段之间的传递依赖。它要求每个非主键字段只依赖于主键，而不依赖于其他非主键字段。
BCNF：主键之间不存在依赖。
数据库类型
关系型数据库和非关系型数据库：
数据库事务必须具备ACID特性，ACID是Atomic原子性，Consistency一致性，Isolation隔离性，Durability持久性。
数据库有几种锁？★★★
共享（S)锁：多个事务可封锁一个共享页；任何事务都不能修改该页； 通常是该页被读取完毕，S锁立即被释放。
排它（X)锁：仅允许一个事务封锁此页；其他任何事务必须等到X锁被释放才能对该页进行访问；X锁一直到事务结束才能被释放。
更新（U)锁：用来预定要对此页施加X锁，它允许其他事务读，但不允许再施加U锁或X锁；当被读取的页将要被更新时，则升级为X锁；U锁一直到事务结束时才能被释放。
数据库的三个完整性约束★★★★
实体完整性，参照完整性和用户自定义完整性约束。
实体完整性规定表的每一行在表中是唯一的实体。
参照完整性指两个表的主关键字和外关键字的数据一致，保证表之间的数据一致性，防止数据丢失或无意义的数据在数据库中扩散。
用户自定义完整性是不同数据库根据应用环境不同，用户定义的一些特殊约束条件。
-
*事务与锁？事务的四个特性是什么？★★★★★
什么是事务？
事务是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。
什么是锁？
锁是用于解决隔离性的一种机制。事务的隔离级别通过锁的机制来实现。
事物的四个特性（ACID）：
原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。
隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。
持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。
存储过程是什么？触发器是什么？为什么要使用存储过程？★★★
存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，它存储在数据库中，一次编译后永久有效(就是把一组操作过程写成代码存好)，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。存储过程是数据库中的一个重要对象。在数据量特别庞大的情况下利用存储过程能达到倍速的效率提升。
触发器（trigger）是SQL server 提供给程序员和数据分析员来保证数据完整性的一种方法，它是与表事件相关的特殊的存储过程，它的执行不是由程序调用，也不是手工启动，而是由事件来触发，比如当对一个表进行操作（ insert，delete，update）时就会激活它执行。触发器经常用于加强数据的完整性约束和业务规则等。
存储过程处理比较复杂的业务时比较实用。 比如说，一个复杂的数据操作。如果你在前台处理的话。可能会涉及到多次数据库连接。但如果你用存储过程的话。就只有一次。从响应时间上来说有优势。 也就是说存储过程可以给我们带来运行效率提高的好处。 另外，程序容易出现 BUG 不稳定，而存储过程，只要数据库不出现问题，基本上是不会出现什么问题的。也就是说从安全上讲，使用了存储过程的系统更加稳定。
1.存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译，而一般 SQL 语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度。 2.当对数据库进行复杂操作时(如对多个表进行 Update,Insert,Query,Delete 时），可将此复杂操作用存储过程封装起来与数据库提供的事务处理结合一起使用。这些操作，如果用程序来完成，就变成了一条条的 SQL 语句，可能要多次连接数据库。而换成存储，只需要连接一次数据库就可以了。 3.存储过程可以重复使用,可减少数据库开发人员的工作量。 4.安全性高,可设定只有某此用户才具有对指定存储过程的使用权。
存储过程的缺点 1：调试麻烦，但是用 PL/SQL Developer 调试很方便！弥补这个缺点。 2：移植问题，数据库端代码当然是与数据库相关的。但是如果是做工程型项目，基本不存在移植问题。 3：重新编译问题，因为后端代码是运行前编译的，如果带有引用关系的对象发生改变时，受影响的存储过程、包将需要重新编译（不过也可以设置成运行时刻自动编译）。 4：如果在一个程序系统中大量的使用存储过程，到程序交付使用的时候随着用户需求的增加会导致数据结构的变化，接着就是系统的相关问题了，最后如果用户想维护该系统可以说是很难很难、而且代价是空前的。维护起来更加麻烦！
数据库的ACID特性，事务回滚，如何解决数据的不一致？事务的ACID特性怎么保证？（REDO/UNDO机制）★★★
Undo Log的原理：为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。除了可以保证事务的原子性，Undo Log也可以用来辅助完成事务的持久化。
数据库对数据处理的过程：先把数据读到内存中，然后修改内存中的数据，最后将数据写回磁盘。
和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，只要将Redo Log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据Redo Log的内容，将所有数据恢复到最新的状态。
redo日志应首先持久化在磁盘上，然后事务的操作结果才写入db buffer，（此时，内存中的数据和data file对应的数据不同，我们认为内存中的数据是脏数据），db buffer再选择合适的时机将数据持久化到data file中。这种顺序可以保证在需要故障恢复时恢复最后的修改操作。先持久化日志的策略叫做Write Ahead Log，即预写日志。
事务隔离级别
数据库事务的隔离级别有4种，由低到高分别为Read uncommitted（读未提交） 、Read committed （读已提交）、Repeatable read （重复读）、Serializable （序列化）。读现象是在多个事务并发执行时，在读取数据方面可能碰到的问题。包括脏读、不可重复读、幻读。
脏读：读到了脏数据，即无效数据。
不可重复读：是指在数据库访问中，一个事务内的多次相同查询却返回了不同数据。
幻读：指同一个事务内多次查询返回的结果集不一样，比如增加了行记录。
备注：不可重复读对应的是修改，即update操作。幻读对应的是插入操作。幻读是不可重复读的一种特殊场景。
要想解决脏读、不可重复读、幻读等读现象，那么就需要提高事务的隔离级别。但是随之带来的，隔离级别越高，并发能力越低。所以，需要根据业务去进行衡量，具体场景应该使用哪种隔离级别。
- 如何优化数据库？提高查询的效率？★★★★★★
https://blog.csdn.net/xlgen157387/article/details/44156679
1、硬件调整性能
最有可能影响性能的是磁盘和网络吞吐量,解决办法扩大虚拟内存，并保证有足够可以扩充的空间；把数据库服务器上的不必要服务关闭掉；把数据库服务器和主域服务器分开；把SQL数据库服务器的吞吐量调为最大；在具有一个以上处理器的机器上运行SQL。
2、调整数据库
若对该表的查询频率比较高，则建立索引；建立索引时，想尽对该表的所有查询搜索操作， 按照where选择条件建立索引，尽量为整型键建立为有且只有一个簇集索引，数据在物理上按顺序在数据页上，缩短查找范围，为在查询经常使用的全部列建立非簇集索引，能最大地覆盖查询；但是索引不可太多，执行UPDATE DELETE INSERT语句需要用于维护这些索引的开销量急剧增加；避免在索引中有太多的索引键；避免使用大型数据类型的列为索引；保证每个索引键值有少数行。
3、使用存储过程（注意：阿里巴巴开发规范中已经明确禁止使用存储过程了，这里只是列出，不作为优化方法！）
应用程序的实现过程中，能够采用存储过程实现的对数据库的操作尽量通过存储过程来实现，因为存储过程是存放在数据库服务器上的一次性被设计、编码、测试，并被再次使用，需要执行该任务的应用可以简单地执行存储过程，并且只返回结果集或者数值，这样不仅可以使程序模块化，同时提高响应速度，减少网络流量，并且通过输入参数接受输入，使得在应用中完成逻辑的一致性实现。
4、应用程序结构和算法
建立查询条件索引仅仅是提高速度的前提条件，响应速度的提高还依赖于对索引的使用。因为人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，特别是对数据量不是特别大的数据库操作时，是否建立索引和使用索引的好坏对程序的响应速度并不大，因此程序员在书写程序时就忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在数据量特别大时或者大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。在对它们进行适当的优化后，其运行速度有了明显地提高！
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/xlgen157387/article/details/44156679
