大家好，我是讯享网，很高兴认识大家。



三范式是关系型数据库中的一种规范，包括第一范式、第二范式和第三范式：

假设我们有一个学生选课表，包含以下字段：学号、姓名、课程名称、教师姓名。这个表可能如下：

1. 第一范式（1NF）：每一列都是不可分割的最小单元。在这个例子中，所有的列（学号、姓名、课程名称、教师姓名）都是最小的数据单元，不能再分割，所以满足第一范式。
2. 第二范式（2NF）：在满足第一范式的基础上，非主属性必须完全依赖于主属性。在这个例子中，如果我们将（学号，课程名称）作为主键，那么其他的列（姓名，教师姓名）都完全依赖于这个主键，所以满足第二范式。
3. 第三范式（3NF）：在满足第二范式的基础上，非主键字段不能依赖于其他非主键字段。在这个例子中，姓名依赖于学号，教师姓名依赖于课程名称，不存在非主键字段相互依赖的情况，所以满足第三范式。

简述来说

第一范式就是没有不可再分的列

第二范式就是满足第一范式的前提下，非主键完全依赖主键

第三范式就是满足第三范式的前提下，非主键之间不互相依赖

为什么要遵循三范式？

 遵循数据库三范式是主要用于减少数据的冗余和方便后续的维护和更新

实际开发中一定要严格遵循三范式吗？为什么？

实际开发中，并不会严格遵循三范式，因为实际工作中，不但要考虑设计三范式之外，还要考虑查询性能

例如，某些场景如果要严格遵循三范式，那么可能需要将多个字段存储到多张表中进行查询，而多张表的联查效率是非常低的，这样情况下为了满足性能的需求，我们通常会涉及冗余字段存放到更少的表中，以减少联表查这就是使用空间换时间的做法询的性能开销，

关系型数据库

关系型数据库适宜于关系模型的数据库，使用表格结构来组织和存储数据，数据是以行和列的形式存储的，并且可以通过定义主键和外键来建立表之间的关系

关系型数据的特点主要有以下几种：

• 统一的数据结构：数据以表格的形式存储，表格由行和列组成，每个列有对应的数据类型，提供了规范和结构化的数据存储方式
• 强一致性：关系型数据库准寻ACID（原子性、一致性、隔离性、持久性）原则，保证数据的一致性和事务的完整性
• 数据完整性：关系型数据库支持定义表之间的关联关系，通过主键和外键进行数据的完整性约束
• 丰富的查询功能：通过SQL查询语言，可以进行复杂的关系查询和连接操作，支持多表查询、条件查询、聚合查询等

关系型数据库的代表：MySQL、Oracle等

非关系型数据库

非关系型数据库（NoSQL），是一种不同于传统关系型数据库系统，他们不依赖于表格和关系模型，而是采用各种不同的数据模型（如键值对、文档、图等）来存储和管理数据，并且放宽了对数据一致性的要求

非关系型数据库的特点主要有以下几种：

• 灵活的数据模型：非关系型数据库可以根据应用的需求选择和定制社和的数据模型，如键值对等
• 高可扩展：非关系型数据库天生支持分布式计算和存储，可以方便地机型横向扩展，以应对大规模数据和高并发访问的需求
• 高性能和高可用：由于非关系型数据库放宽了对一致性的要求，可以进行异步读写和读写分离等优化，从而获取更好的性能和可用性

非关系型数据库的代表：Redis、MongoDB、Neo4j等

关系型数据库和非关系型数据库区别

数据模型不同：

• 关系型数据库：基于关系模型，数据以表格形式存储，每个表都有预定义的列和数据类型。表与表之间通过外键建立关系，形成一个相互关联的数据集合
• 非关系型数据库：不采用表格和关系模型，数据可以以各种形式存储，如键值对、文档、图形等

数据结构不同：

• 关系型数据库：数据结构与严格，需要预先定义好结构和字段类型，数据修改通常需要遵循一定的规范和约束
• 非关系型数据库：数据结构灵活，无需预先定义严格的模式，可以根据需要随时添加或者修改数据结构

查询语言不同：

• 关系型数据库：通常使用SQL进行查询，支持复杂的查询条件、连接操作和聚合函数
• 非关系型数据库：查询语言因数据库类型而异，有些支持类似SQL的查询语法，有些则使用特定的API或DSL（领域特定语言）

事务支持不同：

• 关系型数据库：通常支持ACID（原子性、隔离性、一致性、持久性）事物特征，保证数据的一致性和完整性
• 非关系型数据库：事务支持程度因数据库类型而异，只有少量的NOSQL数据库可能只提供部分ACID特性，或者采用不同的一致性模型

扩展性与性能不同

讯享网

• 关系型数据库：传统的关系型数据库在水平扩展方面可能存在挑战，通产通过垂直扩展（增加单台服务器的硬件资源）来提高性能
• 非关系型数据库：设计上通常更易于水平扩展，通过添加更多的服务器来分散数据和负载

应用场景

• 关系型数据库：适用于需要高度一致性和复杂查询场景，如金融交易，企业级应用和内容管理系统等
• 非关系型数据库：适用于海量数据存储、日志系统、大数据分析、实时处理、Web应用和移动应用等领域，尤其在处理半结构和非半结构化数据时具有优势

存储引擎就是如何存储数据、如何为存储数据建立索引和如何更新、查询数据等技术的实现方法。因为在关系型数据库中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型（即存储和操作此表类型）

MySQL常用的存储引擎有以下几种：

InnoDB：MySQL(5.5+)的默认存储引擎，支持事务处理、行级锁定和物理外键约束

• 特征：提供良好的数据一致性、崩溃恢复和高并发性能
• 使用场景：适用于需要事务支持和多用户读写操作应用场景

MyISAM：MySQL早期默认存储引擎，不支持事务和行级锁定

• 特征：提供快速的读取速度和较小的数据存储文件
• 使用场景：适用于只读或读多写少的环境，不需要事务的场景

MEMORY：将表的数据存储在内存中，提供极快的访问速度

• 特征：数据在服务器重启后会丢失
• 使用场景：适用于临时表、缓存表或者需要快速查询的小型表

InnoDB和MyISAM是MySQL的两种常用的存储引擎，它们的主要的区别就是：

1.  事务支持不同：InnoDB支持事务，MyISAM不支持事务
2. 锁粒度不同：InnoDB支持最小的锁粒度为行级锁，MyISAM支持最小的锁粒度是表级锁
3. 外键支持不同：InnoDB支持物理外键，MyISAM不支持物理外键
4. 索引存储方式不同：InnoDB索引叶子节点存储的是当前行的数据，MyISAM索引的叶子节点存储的是地址，根据地址才能获取当前行的数据

"锁粒度"是指数据库管理系统在进行数据操作时，对数据加锁的范围。不同的数据库管理系统或者不同的存储引擎，支持的锁粒度可能会有所不同。

InnoDB和MyISAM是MySQL数据库的两种常见的存储引擎，它们支持的锁粒度不同：

• InnoDB支持的最小锁粒度是行级锁。这意味着当InnoDB需要对数据进行操作时，它可以锁定单独的一行数据，而不会影响到其他行的读写操作。这种锁粒度较小，可以提高并发性能，但是管理这种锁的开销也相对较大。
• MyISAM支持的最小锁粒度是表级锁。这意味着当MyISAM需要对数据进行操作时，它会锁定整个表，其他的读写操作必须等待锁被释放后才能进行。这种锁粒度较大，管理这种锁的开销较小，但是并发性能较低。

也就是说物理外键会存在一些问题：

性能问题：插入之前会先去主键中查询，性能较慢

可能会带来数据库更新风暴问题：数据库更新风暴是指在一个较短的时间内，大量的并发数据库更新操作集中发生，导致数据库服务器在处理这些请求的时候面临巨大压力，可能引起性能瓶颈、延迟增大设置系统崩溃现象。这种情况通常发生在高并发的情况下

物理删除和逻辑删除的定义如下：

• 物理删除：物理删除是指直接从数据库中永久删除数据记录。物理删除会直接删除相应的数据库行，并释放相关的存储空间。被删除的数据将无法恢复，且不在对应原有的唯一标志
• 逻辑删除：逻辑删除是指在程序中实现“删除功能”，通常是通过添加一个标记字段或者状态字段来标记该数据为已删除状态。逻辑删除不会直接删除数据记录，而恶是将数据状态字段标记成已删除状态，表示该数据不再有效。逻辑删除可以在业务逻辑是数据不可见，但是数据仍然存在数据库中，逻辑删除可以通过修改查询来筛选出删除或已删除状态的数据

在日常开发中，使用哪种删除方式会取决于具体的需求和业务场景：

• 大部分情况下，对重要的数据，在数据库空间和性能满足的情况下，会采用逻辑删除。这样好处是可以保留历史数据，方便后续数据恢复和保证数据的完整性
• 如果是不重要的数据，例如具有时效性的一些日志数据，且数据库对性能和空间有要求的场景下，会使用物理删除来节约系统空间，和提高查询性能

内连接和外连接是SQL中用于连接多个表的操作：

内连接：最常用的连接类型之一，他根据两个或者多个表之间共同列值来连接这些表。在内连接中，只有再连接的表之间匹配值的时候，才会有返回结果。例如：

讯享网

外连接：是另一种连接类型，他可以返回两个或者多个表之间所有的匹配和不匹配的数据。外连接有三种类型：左外连接（LEFT OUTER JOIN）、右外连接(RIGHT OUTER JOIN)和全外连接（FULL OUTER JOIN）。例如：

讯享网

它们的区别是：内连接返回的是两个表都存在的数据，如图：

 左（右）外连接是左（右）表的所有数据和右（左）表匹配的数据，如图：

全外查询到的数据，如图：

 自连接是一种特殊的表连接，它是指相互连接的表在物理上同为一张表，但是逻辑上是多张表。自连接通常用于表中的数据有层次结构的情况

假设我们有一个员工表，如下所示：

在这个表中，每个员工都有一个经理，经理也是员工表中的一员。我们可以通过自连接查询出每个员工的经理的姓名。

这个查询的结果将是：

创建索引的时候是否会锁表取决于MySQL的版本，在MySQL5.7之前，创建索引会锁表，所以在早期MySQL中一定要在线上慎用，因为创建索引时会导致其他会话阻塞（select除外）。这是因为在创建索引的过程中，需要保证表的数据不被修改，以确保所i引得正确性和一致性

然而在MySQL5.7之后，MySQL引入了Online DDL计数。这项技术允许在创建索引的时候，不阻塞其他会话（所有的DML（数据操作语言INSERT、UPDATE、DELETE、SELECT）操作一起并发执行）。这是因为Online DDL技术允许在数据库运行期间执行对表结构或者其他数据库对象的更改操作，而不需要中断其他正在进行的事务和查询

聚簇索引和非聚簇索引是两种常见的索引类型，他们在数据存储和检索方式上有一些重要的区别：

• 聚簇索引：在聚簇索引中，数据按照索引列的值顺序存储在同一个页上。这意味着索引和数据是存储在一起的，找到索引就找到了数据。因此，通过聚簇索引可以直接找到真正的行数据。在MySQL的InnoDB引擎中，聚簇索引默认是主键
• 非聚簇索引：非聚簇索引将索引和数据行分开存储，索引结构的叶子结点指向了数据对应的位置。在非聚簇索引的叶子节点上存储的并不是真正的行数据，而是主键ID。所以我们使用非聚簇索引进行查询的时候，首先会得到一个主键ID，然后使用主键ID去聚簇索引上寻找真正的行数据，我们把这个过程称为回表查询

总结一下，聚簇索引和非聚簇索引的区别主要是以下几种：

• 聚簇索引的叶子节点存储的是行数据；而非聚簇索引叶子节点存储的是聚簇索引（通常书主键ID）
• 聚簇索引查询效率更高，而非聚簇索引需要进行回表查询，因此性能不如聚簇索引
• 聚簇索引一般为主键索引，而主键一个表中只可以有一个，因此聚簇索引一个表中也只能有一次，而非聚簇索引一个表中可以有多个

聚簇索引

聚簇索引（Clustered Index）一般指的是主键索引（如果存在主键索引的话），聚簇索引也被称之为聚集索引。

聚簇索引在 InnoDB 中是使用 B+ 树实现的，比如我们创建一张 student 表，它的构建 SQL 如下：

以上 student 表中有一个聚簇索引（也就是主键索引）id，和一个非聚簇索引 class_id。

聚簇索引 id 对应的 B+ 树如下图所示：

在聚簇索引的叶子节点直接存储用户信息的内存地址，我们使用内存地址可以直接找到相应的行数据。

非聚簇索引

非聚簇索引在 InnoDB 引擎中，也叫二级索引，以上面 student 表为例，在 student 中非聚簇索引 class_id 对应 B+ 树如下图所示：

从上图我们可以看出，在非聚簇索引的叶子节点上存储的并不是真正的行数据，而是主键 ID，所以当我们使用非聚簇索引进行查询时，首先会得到一个主键 ID，然后再使用主键 ID 去聚簇索引上找到真正的行数据，我们把这个过程称之为回表查询。

总结

在 MySQL 的 InnoDB 引擎中，每个索引都会对应一颗 B+ 树，而聚簇索引和非聚簇索引最大的区别在于叶子节点存储的数据不同，聚簇索引叶子节点存储的是行数据，因此通过聚簇索引可以直接找到真正的行数据；而非聚簇索引叶子节点存储的是主键信息，所以使用非聚簇索引还需要回表查询，因此我们可以得出聚簇索引和非聚簇索引的区别主要有以下几个：

• 聚簇索引叶子节点存储的是行数据；而非聚簇索引叶子节点存储的是聚簇索引（通常是主键 ID）。
• 聚簇索引查询效率更高，而非聚簇索引需要进行回表查询，因此性能不如聚簇索引。
• 聚簇索引一般为主键索引，而主键一个表中只能有一个，因此聚簇索引一个表中也只能有一个，而非聚簇索引则没有数量上的限制。

聚簇索引大多数情况下是等于主键索引的（如果主键存在的情况），但是如果表中没有主键索引的情况下，聚簇索引就等于其他的索引类型了。

聚簇索引的生成规则

如果有主键索引的时候，那么聚簇索引就等于主键索引，如果没有主键索引，那么聚簇索引的诞生流程依次如下：

• 无主键索引，则使用非空唯一索引：如果表中没有主键索引，你那么InnoDB会使用第一个唯一的索引（unique），且此唯一索引设置了非空约束（not null），我们就使用它做i为聚簇索引
• 无任何满足的索引，则生成隐藏聚簇索引：如果一张表既没有主键索引，也没有唯一索引，那么InnoDB会生成一个名为GEN_CLUST_INDEX的隐藏聚簇索引，这个隐藏的索引为六字节长整型类型