• 第一范式（1NF）：每个列都不可以再拆分，强调的是列的原子性。第一范式要求数据库中的表都是二维表。
• 第二范式（2NF）：在第一范式的基础上，一个表必须有一个主键，非主键列 完全依赖 于主键，而不能是依赖于主键的一部分。
• 第三范式（3NF）：在第二范式的基础上，非主键列只依赖（直接依赖）于主键，不依赖于其他非主键。

数据库连接泄露的含义

• 通过创建 唯一性索引，可以保证数据库表中每一行数据的唯一性；
• 可以加快数据的 检索速度，这也是创建索引的主要原因；
• 可以加速表和表之间的连接，特别是在实现 数据的参考完整性 方面特别有意义；
• 通过使用索引，可以在查询的过程中，使用 优化隐藏器，提高系统性能。

B 树索引以 树结构 组织，它有一个或者多个分支结点，分支结点又指向单级的叶结点。其中，分支结点用于遍历树，叶结点则保存真正的值和位置信息。

B+ 树是在 B 树基础上的一种优化，使其更适合实现外存储索引结构。

一棵 m 阶 B-Tree 的特性如下：

• 每个结点最多 m 个子结点；
• 除了根结点和叶子结点外，每个结点最少有 m/2（向上取整）个子结点；
• 所有的叶子结点都位于同一层；
• 每个结点都包含 k 个元素（关键字），这里 m/2≤k<m，这里 m/2 向下取整；
• 每个节点中的元素（关键字）从小到大排列；
• 每个元素子左结点的值，都小于或等于该元素，右结点的值都大于或等于该元素。

数据库以 B-Tree 的数据结构存储数据的图示如下：


B+ Tree 与 B-Tree 的结构很像，但是也有自己的特性：

• 所有的非叶子结点只存储 关键字信息；
• 所有具体数据都存在叶子结点中；
• 所有的叶子结点中包含了全部元素的信息；
• 所有叶子节点之间都有一个链指针。

数据库以 B+ Tree 的数据结构存储数据的图示如下：

Hash 索引
哈希索引采用一定的 哈希算法（常见哈希算法有 直接定址法、平方取中法、折叠法、除数取余法、随机数法），将数据库字段数据转换成定长的 Hash 值，与这条数据的行指针一并存入 Hash 表的对应位置，如果发生 Hash 碰撞（两个不同关键字的 Hash 值相同），则在对应 Hash 键下以 链表形式 存储。

检索时不需要类似 B+ 树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快，平均检索时间为 O(1)。

位图索引
B 树索引擅长于处理包含许多不同值的列，但是在处理基数较小的列时会变得很难使用。如果用户查询的列的基数非常的小， 即只有几个固定值，如性别、婚姻状况、行政区等等，要么不使用索引，查询时一行行扫描所有记录，要么考虑建立位图索引。

位图索引为存储在某列中的每个值生成一个位图。例如针对表中婚姻状况这一列，生成的位图索引大致如下所示：

CREATE BITMAP INDEX acc_marital_idx ON account (marital_cd);

• 活跃状态：事务的第一个状态，任何正在执行的事务都处于此状态，所做的 更改 存储在 主内存的缓冲区 中。
• 部分提交状态：执行上次操作后，事务进入部分提交状态。之所以是部分提交，是因为所做的更改仍然在主内存的缓冲区中。
• 失败状态：如果某个检查在活动状态下失败，在活动状态或部分提交状态发生一些错误，并且事务无法进一步执行，则事务进入失败状态。
• 中止状态：如果任何事务已达到失败状态，则恢复管理器将数据库回滚到开始执行的原始状态。
• 提交状态：如果所有操作成功执行，则来自 部分提交状态 的事务进入提交状态。无法从此状态回滚，它是一个新的 一致状态。

事务的四大特性

如何实现事务的 ACID 特性

事务的 ACID 特性是由关系数据库管理系统来实现的。

DBMS 采用 日志 来保证事务的 原子性、一致性 和 持久性。日志记录了事务对数据库所做的更新，如果某个事务在执行过程中发生错误，就可以根据日志，撤销事务对数据库已做的更新，使数据库退回到执行事务前的初始状态。

DBMS 采用 锁机制 来实现事务的隔离性。当多个事务同时更新数据库中相同的数据时，只允许 持有锁的事务 能更新该数据，其他事务必须等待，直到前一个事务释放了锁，其他事务才有机会更新该数据。

事务之间的相互影响

脏读（Dirty Read）
一个事务读取了另一个事务未提交的数据。

不可重复读（Non-repeatable Read）
就是在一个事务范围内，两次相同的查询会返回两个不同的数据，这是因为在此间隔内有其他事务对数据进行了修改。

幻读（Phantom Read）
幻读是指当事务 不是独立执行时 发生的一种现象，例如有一个事务对表中的数据进行了修改，这种修改涉及到表中的全部数据行，同时，第一个事务也修改这个表中的数据，这种修改是向表中 插入一行新数据。那么，第一个事务的用户发现表中还有没有修改的数据行，就好像发生了幻觉一样。

丢失更新（Lost Update）
两个事务同时读取同一条记录，事务 A 先修改记录，事务 B 也修改记录（B 是不知道 A 修改过），当 B 提交数据后， 其修改结果覆盖了 A 的修改结果，导致事务 A 更新丢失。

什么是事务的隔离级别

为了尽可能的避免上述事务之间的相互影响，从而达到事务的四大特性，SQL 标准定义了 4 种不同的事务隔离级别（TRANSACTION ISOLATION LEVEL），即 并发事务对同一资源的读取深度层次，由低到高依次是 读取未提交（READ-UNCOMMITTED）、读取已提交（READ-COMMITTED）、可重复读（REPEATABLE-READ）、可串行化（SERIALIZABLE），这 4 个级别与事务相互间影响问题对应如下：

锁

在上一章中，提及事务之间的相互影响时，介绍了脏读、幻读等几种类型的数据错误，为更好避免发生这些错误，引入了对资源的锁定。锁定的存在使得一个事务对他自己的数据块进行操作时，另外一个事务不能插足这个数据块。

锁的分类

从数据库系统的角度，锁模式可分为以下6 种类型：

• 共享锁（S）：又叫 他读锁。可以并发读取数据，但不能修改数据。也就是说当数据资源上存在共享锁时，所有的事务都不能对该数据进行修改，直到数据读取完成，共享锁释放。
• 排它锁（X）：又叫 独占锁、写锁。对数据资源进行增删改操作时，不允许其它事务操作这块资源，直到排它锁被释放，从而防止同时对同一资源进行多重操作。
• 更新锁（U）：防止出现 死锁 的锁模式，两个事务对一个数据资源进行先读取再修改的情况下，使用共享锁和排它锁有时会出现死锁现象，而使用更新锁就可以避免死锁的出现。

• 意向锁：表示 SQL Server 需要在 层次结构中的某些底层资源上 获取共享锁或排它锁。例如，放置在 表级 的 共享意向锁 表示事务打算在表中的页或行上放置共享锁。在表级设置意向锁可防止另一个事务随后在包含那一页的表上获取排它锁。

• 架构锁：在执行 依赖于表架构的操作 时使用。架构锁的类型为：架构修改 (Sch-M) 和架构稳定性 (Sch-S)，执行表的数据定义语言 （DDL）操作（例如添加列或除去表）时使用架构修改锁，当编译查询时，使用架构稳定性锁。
• 大容量更新锁（BU）：向表中大容量复制数据并指定了 TABLOCK 提示时使用。 大容量更新锁允许进程将数据并发地大容量复制到同一表，同时防止其它不进行大容量复制数据的进程访问该表。

事务隔离级别与锁的关系

• 在 读取未提交 隔离级别下，读取数据不需要加 共享锁，这样就不会跟被修改的数据上的 排他锁 冲突；
• 在 读取已提交 隔离级别下，读操作需要加 共享锁，但是在语句执行完以后释放共享锁；
• 在 可重复读 隔离级别下，读操作需要加 共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁；
• 可串行化 是限制性最强的隔离级别，因为该级别 锁定整个范围的键，并一直持有锁，直到事务完成。

什么是死锁？如何解决死锁？

• 如果不同程序并发存取多个表，尽量约定 以相同的顺序访问表，可以大大降低死锁机会；
• 在同一个事务中，尽可能做到 一次锁定所需要的所有资源，减少死锁产生概率；
• 对于非常容易产生死锁的业务部分，可以尝试使用 升级锁定颗粒度，通过 表级锁 定来减少死锁产生的概率。

什么是乐观锁和悲观锁？如何实现？

DBMS 中的 并发控制 的任务是确保在 多个事务同时存取数据库中同一数据 时不破坏事务的隔离性和统一性以及数据库的统一性。乐观并发控制（乐观锁）和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。在查询完数据的时候就把事务锁起来，直到提交事务。这对于长事务来讲，可能会严重影响系统的并发处理能力。实现方式：使用数据库中的锁机制。

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁适用于 读多写少 的应用场景，这样可以提高吞吐量。实现方式：一般会使用版本号机制或 CAS 算法实现。

常用 SQL 语句

SQL 语句主要分为哪些类别

• 数据定义语言 DDL（Data Ddefinition Language）：例如 CREATE，DROP，ALTER 等，对逻辑结构等有操作的，其中包括表结构，视图和索引。
• 数据查询语言 DQL（Data Query Language）：即查询操作，以 SELECT 关键字为主，各种简单查询、连接查询等都属于 DQL。
• 数据操纵语言 DML（Data Manipulation Language）：例如 INSERT，UPDATE，DELETE 等，对数据进行操作的。DQL 与 DML共同构建了多数初级程序员常用的 增删改查 操作，而查询是较为特殊的一种，被划分到 DQL 中。
• 数据控制功能 DCL（Data Control Language）：例如 GRANT，REVOKE，COMMIT，ROLLBACK 等，对数据库安全性、完整性等有操作的，可以简单的理解为权限控制等。

什么是超键？什么是主键？

• 超 键：在关系中，能唯一标识元组的属性集称为关系模式的超键。一个属性可以作为一个超键，多个属性组合在一起也可以作为一个超键。超键包含候选键和主键。
• 候选键：是最小超键，即没有冗余元素的超键。
• 主 键：数据库表中对储存数据对象予以 唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键，且主键的取值不能缺失，即不能为空值（NULL）。
• 外 键：在一个表中存在的另一个表的主键称此表的外键，外键可以有重复的, 可以是空值。外键是用来和其他表建立联系用的。

SQL 约束有哪几种类型

约束是一种简单地强加于表中一列或多列的限制，从而保证表中数据一致性（准确和可靠）。以下为六大约束：

• 非空约束（NOT NULL）：保证该字段值一定不为空；
• 默认约束（DEFAULT）：保证字段有默认值；
• 主键约束（PRIMARY KEY）：标志一列或者多列，并保证其值在表内的唯一性；
• 外键约束（FOREIGN KEY）：限制一列或多列中的值必须被包含在另一表的外键列中，并且在级联更新或级联删除规则建立后也可以限制其他表中的可用值；
• 唯一约束（UNIQUE）： 限制一列或多列的值，保证字段值在表内的唯一性，可以为空（主键约束是一种特殊类型的唯一约束）；
• 检查约束（CHECK）：限制一列的可用值范围。

char 与 varchar 的区别

• 交叉连接（CROSS JOIN）

SELECT  *  FROM  A, B
SELECT  *  FROM  A  CROSS JOIN  B

• 联合查询（UNION 与 UNION ALL）

SELECT * FROM A UNION SELECT * FROM B UNION ...

• 全连接（FULL JOIN）

SELECT * FROM A LEFT JOIN B ON A.id = B.id UNIONSELECT * FROM A RIGHT JOIN B ON A.id = B.id

什么是子查询

子查询的分类

DROP、DELETE 与 TRUNCATE 的区别

UNION 与 UNION ALL 的区别

Redis 常见面试题

Redis 缓存的特点

Redis 和 MySQL 的区别

• 首先，类型上的不同。MySQL 是关系型数据库，采用表格的存储方式，数据以行列组织：一个表中，每行是一个条目，都有且仅有此表的列所规定的属性。MySQL 作为关系型数据库遵守了传统的数据库的 ACID 原则 [①]，这些要求在记录重要数据（如用户账户密码，银行户头等）时是必须的。Redis 是 NoSQL（非关系型数据库），不严格遵守 ACID 原则，其采用 key-value 存储组织数据，大量使用缓存来读写数据，周期性地把更新数据写入磁盘或在追加文件中写入修改操作，以及同步分布数据库等。这些特点为大大提高了 Redis 在极大并发量下的读写性能。由于不以表格方式组织数据，Redis 的数据扩展十分灵活方便。
• 功能不同。 MySQL 主要用于持久化的存储数据到硬盘，功能强大，但是读取速度较慢。而 Redis 将使用频繁的数据存储在缓存中，缓存的读取速度快，能够大大的提高运行效率，但是一般在使用中，Redis 缓存的数据保存时间是有限的。
• 运行机制不同。MySQL 作为典型的关系型数据库，为了严格遵守 ACID 规则必须采取保守的缓存策略，特别是为了保证数据的一致性，在保证数据可靠性的同时，牺牲了许多（特别是多并发情形下的）读写性能。而现在互联网许多应用场景往往面临了海量用户的访问请求，对数据库并不需要非常强的一致性 [②]。如 Redis 等非关系型数据库（NoSQL），往往以不再满足 ACID 为代价求得更高的吞吐容量。NoSQL 通常采用极大的缓存、分布式服务来提高读写性能。

Redis 和 MongoDB 的区别

MongoDB 和 Redis 都是 NoSQL，采用结构型数据存储，二者之间的主要区别如下所示：

• 性能方面，二者都很高，总体而言，TPS 方面 Redis 要大于 MongoDB；
• 可操作性上，MongoDB 支持丰富的数据表达、索引，最类似于关系数据库，支持 丰富的查询语言，操作比 Redis 更为便利；
• 内存及存储方面，MongoDB 适合 大数据量存储，依赖操作系统虚拟做内存管理，采用镜像文件存储，内存占有率比较高，Redis 2.0 后增加 虚拟内存特性，突破物理内存限制，数据可以设置时效性；
• 对于数据持久化和数据恢复，MongoDB 1.8 后，采用 binlog 方式（同 MySQL）支持持久化，增加了可靠性，而 Redis 依赖快照进行持久化、AOF 增强可靠性，但是增强可靠性的同时，也会影响访问性能；
• 在数据一致性上，MongoDB 不支持事务，靠客户端自身保证，而 Redis 支持事务，能保证事务中的操作按顺序执行；
• 数据分析上，MongoDB 内置 数据分析功能（mapreduce），而 Redis 不支持数据分析；
• 应用场景不同，MongoDB 适合海量数据，侧重于访问效率的提升，而 Redis 适合于较小数据量，侧重于性能。

Redis 有哪些数据类型

数据库优化

系统的吞吐量瓶颈往往出现在数据库的 访问速度 上，随着应用程序的运行，数据库的中的数据会越来越多，处理时间会相应变慢，因为其数据是存放在 磁盘 上的，读写速度无法和内存相比，所以使用数据库时，十分有必要了解数据库优化问题。其优化原则为：减少系统瓶颈，减少资源占用，增加系统的反应速度。

数据库结构优化

为什么要分库分表

分库分表的具体实施策略