finished all

docs/MySQL/05 存储引擎.md

@@ -168,7 +168,7 @@ create table T(
 > **基于主键索引和普通索引的查询有什么区别**?
 
 - 如果语句是 select * from T where ID=500，即主键查询方式，则只需要搜索 ID 这棵 B+ 树；
-- 如果语句是 select * from T where k=5，即普通索引查询方式，则需要先搜索 k 索引树，得到 ID 的值为 500，再到 ID 索引树搜索一次。这个过程称为回表。
+- 如果语句是 select * from T where k=5，即普通索引查询方式，则需要先搜索 k 索引树，得到 ID 的值为 500，再到 ID 索引树搜索一次。**这个过程称为回表**。
 
 也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。
 

docs/MySQL/33 数据库三大范式.md

@@ -0,0 +1,80 @@
+---
+sidebarDepth: 3
+sidebar: auto
+prev:
+  text: Back To 目录
+  link: /MySQL/
+typora-root-url: ..\.vuepress\public
+---
+
+
+
+## 第一范式（1NF）
+
+**第一范式（1NF）**：确保每个数据列都是**不可再分的原子值**，即每个单元格中只包含一个值。这可以通过将表拆分为更小的表来实现，每个表都包含一个实体的属性。
+
+地址还可以拆分
+
+| 地址ID                   | 地址详情                              |
+| ------------------------ | ------------------------------------- |
+| 202311212056485430000081 | 内蒙古呼和浩特市新城区团结小区7号楼   |
+| 202311231036360980000279 | 内蒙古呼和浩特市赛罕区万达一区底商101 |
+
+遵循第一范式
+
+![image-20240320201655059](/images/MySQL/image-20240320201655059.png)
+
+
+
+## 第二范式（2NF）
+
+**第二范式（2NF）**：建立在第一范式的基础上，要求表中的每个非主键列完全依赖于主键列，而不是依赖于其他非主键列。换句话说，每个表应该只描述一个实体的信息。如果有部分信息依赖于表中的一部分主键，那么需要将这些信息拆分到另一个表中。
+
+![image-20240320201841196](/images/MySQL/image-20240320201841196.png)
+
+- 购买价格：购买价格完全依赖订单编号+产品编号，订单编号+产品编号同时确定才能确定购买价格（同一产品在不同的订单会有不同的价格）；
+
+- 购买数量：购买数量完全依赖订单编号+产品编号；订单编号+产品编号同时确定才能确定购买数量；
+
+- 订单总金额：订单总金额只依赖于订单编号，和实际的产品没有关系，我们通过订单编号就可以明确订单总金额；所以该字段违背了第二范式（2NF）；
+
+- 购买时间：购买时间只依赖于订单编号，一个订单的所有商品肯定是同一时间购买的，该字段很明显和产品编号是无任何依赖关系的；所以该字段也违背了第二范式（2NF）。
+
+现在我们进行优化，进行表拆分，拆分后得到两个表：
+
+![image-20240320201951368](/images/MySQL/image-20240320201951368.png)
+
+## 第三范式（3NF）
+
+**第三范式（3NF）**：在第二范式的基础上，要求表中的每个非主键列之间不应该存在传递依赖关系。也就是说，非主键列之间不应该相互依赖，而是直接依赖于主键列。如果存在传递依赖，需要将其转化为直接依赖关系。
+
+| 部门ID                   | 部门名称   | 负责人 | 负责人性别 | 负责人年龄 |
+| ------------------------ | ---------- | ------ | ---------- | ---------- |
+| 202311212056485430000001 | 综合支撑部 | 张三   | 男         | 35         |
+| 202311212056485430000002 | 人力资源部 | 李四   | 男         | 41         |
+
+部门名称和负责人和部门ID是直接关联了，而负责人性别和负责人年龄和部门ID并没有直接关系，而是和负责人直接关联的，所以就存在这种传递依赖关系了。
+
+> 部门ID->负责人->负责人性别 部门ID->负责人->负责人年龄
+
+| 部门ID                   | 部门名称   | 负责人ID                 |
+| ------------------------ | ---------- | ------------------------ |
+| 202311212056485430000001 | 综合支撑部 | 202311212056485430000003 |
+| 202311212056485430000002 | 人力资源部 | 202311212056485430000004 |
+
+| 负责人ID                 | 姓名 | 性别 | 年龄 |
+| ------------------------ | ---- | ---- | ---- |
+| 202311212056485430000003 | 张三 | 男   | 35   |
+| 202311212056485430000004 | 李四 | 男   | 41   |
+
+
+
+## 总结
+
+1. 第一**范式**(确保每列保持原子性)
+2. 第二**范式**(确保表中的每列都和主键相关)
+3. 第**三范式**(确保每列都和主键列直接相关,而不是间接相关)
+
+## 参考
+
+[一文彻底搞懂数据库三范式 - 掘金 (juejin.cn)](https://juejin.cn/post/7336799230978326565)

docs/MySQL/35 为什么MySQL默认引擎是InnoDB.md

@@ -0,0 +1,22 @@
+---
+sidebarDepth: 3
+sidebar: auto
+prev:
+  text: Back To 目录
+  link: /MySQL/
+typora-root-url: ..\.vuepress\public
+---
+
+
+
+MySQL 默认的存储引擎是 InnoDB，这是因为 InnoDB 在性能、事务支持和容错能力等方面具有较好的特性，适合大多数应用场景。下面是一些原因：
+
+1. **支持事务：**InnoDB 是一个支持事务的存储引擎。事务是一组数据库操作的原子性执行，可以保证操作的一致性和完整性。
+2. **并发控制**：**InnoDB 支持行级锁定**，在高并发环境下可以最大程度地减少锁冲突，提高并发性能。相比之下，MySQL 的另一个存储引擎 MyISAM 只支持表级锁定，并发性能较低。
+3. **外键约束：**InnoDB 支持外键约束，可以保证数据的完整性。外键用于建立表与表之间的连接，通过外键约束可以实现数据之间的关联和参照完整性。
+4. **崩溃恢复：**InnoDB 具有自动崩溃恢复的能力。即使在发生意外故障或系统崩溃时，InnoDB 引擎也能够自动进行崩溃恢复，保障数据的一致性。
+5. **持热备份：**InnoDB 支持在线热备份，可以在不停止数据库服务的情况下进行备份操作。这对于需要实时运行且对数据可用性要求高的应用程序非常重要
+
+
+需要注意的是，虽然 InnoDB 是 MySQL 默认的存储引擎，但在某些场景下，可以根据实际需求选择其他存储引擎，如 MyISAM、Memory 等。不同的存储引擎适用于不同的应用场景和需求。
+