目录
三大范式
第一范式:
第二范式:
第三范式:
巴斯-科德范式(BCNF):
反范式：
MySQL的工作原理
三大范式
第一范式:
一个字段只表明一个事情
优点:
数据一致性：
在1NF中，由于每个属性都是原子的，因此避免了在一个属性中存储多个值的情况。这有助于确保数据的一致性和准确性，因为每个值都是清晰定义的，并且没有混淆。减少数据冗余的潜力：
虽然1NF本身并不直接消除数据冗余，但它为进一步的规范化提供了基础。通过将属性拆分为更小的、原子的部分，可以更容易地识别并消除冗余数据。简化数据操作：
在1NF中，每个属性都包含单一的值，这使得数据插入、更新和删除操作更加简单和直接。避免了在一个属性中处理多个值所带来的复杂性。提高查询效率：
虽然1NF本身并不直接提高查询效率，但通过将数据组织成更小的、更清晰的单元，可以更容易地构建高效的查询。此外，1NF还有助于避免在查询过程中进行不必要的数据拆分和转换。为高级范式打下基础：
1NF是数据库规范化的起点，它为后续的第二范式（2NF）、第三范式（3NF）和BCNF（Boyce-Codd Normal Form）等高级范式提供了基础。通过满足1NF的要求，可以更容易地进一步规范化数据库，以消除部分依赖、传递依赖和冗余数据。缺点：
数据冗余：
在1NF中，数据冗余是可能的。因为只要每个属性都是原子的，表中就可以有重复的数据。这种冗余可能导致存储空间的浪费，并增加数据更新和维护的复杂性。更新异常：
由于数据冗余，当需要更新某个数据时，可能需要在多个地方进行修改。这不仅增加了操作的复杂性，还可能导致数据不一致的风险。插入异常：
如果表中有某些属性是可选的，但在某些情况下这些属性对于完整记录是必要的，那么在1NF中可能会遇到插入问题。例如，如果有一个包含学生和其选修课程的表，而学生可能选修多门课程，那么在1NF中，为了插入一个学生的部分课程信息，可能需要插入一个不完整的记录。删除异常：
与插入异常类似，删除数据时也可能导致问题。如果删除了一个包含重要信息的记录，那么与该记录相关的其他信息也可能被丢失，即使这些信息在其他上下文中仍然是有用的。
第二范式:
建立在第一范式的基础上。
若是数据冗余了不好区分所以加上主键可以进行区分
优点
消除部分依赖：
第二范式要求数据库表中的每个非主属性都完全依赖于主键，而不是仅仅依赖于主键的一部分。这有助于消除部分依赖，即某个属性只依赖于主键的一部分的情况。通过消除部分依赖，可以减少数据冗余和更新异常。提高数据一致性：
当非主属性完全依赖于主键时，可以确保数据的一致性。因为每个非主属性都与主键有直接的联系，所以当主键的值发生变化时，可以更容易地更新相关的非主属性，从而保持数据的一致性。减少数据冗余：
通过消除部分依赖，第二范式有助于减少数据冗余。例如，如果有一个学生表，其中包含了学生的学号、姓名、系名和系主任等信息，那么按照第二范式的要求，可以将系名和系主任等信息单独放在一个系表中，从而避免在学生表中重复存储这些信息。简化数据操作：
在第二范式中，由于每个非主属性都完全依赖于主键，因此数据插入、更新和删除操作更加简单和直接。避免了在一个表中处理多个相关属性所带来的复杂性。缺点
第三范式:
第三范式就是在第二范式的基础上进行分表比如说把部门建成一个从表让从表的信息和主表进行间接连接
优点
减少数据冗余：
第三范式要求非主键字段必须直接依赖于主键，不能存在传递依赖。这意味着每个非主键字段都直接与主键相关联，避免了通过其他非主键字段进行间接关联的情况。这有助于减少数据冗余，节省存储空间。提高数据一致性和完整性：
由于第三范式消除了传递依赖，确保了每个非主键字段都直接依赖于主键，因此当主键的值发生变化时，可以更容易地更新相关的非主键字段，从而保持数据的一致性和完整性。此外，第三范式还有助于避免数据插入异常、删除异常和更新异常等问题。简化数据维护：
在第三范式中，数据被分解为更小的、更清晰的单元，这使得数据的维护变得更加简单和直接。当需要对数据进行修改、更新或优化时，可以更容易地定位到相关的表和字段。提高查询效率：
虽然第三范式可能导致查询时需要执行更多的表连接操作，但在某些情况下，通过减少数据冗余和避免不必要的字段，可以提高查询效率。特别是当查询涉及大量数据时，减少冗余数据可以显著减少查询时间和计算成本。缺点
可能导致查询复杂化：
为了满足第三范式的要求，可能需要将原始表拆分成多个表，并通过外键进行关联。这可能导致查询时需要执行更多的表连接操作，增加了查询的复杂性。特别是在处理复杂查询时，可能需要编写更复杂的SQL语句或使用更高级的查询技术。增加表的数量：
与第二范式类似，第三范式也可能导致数据库中表的数量增加。这增加了数据库管理的复杂性，特别是在需要频繁进行表连接操作的情况下。可能影响性能：
虽然第三范式有助于提高数据的一致性和完整性，但过多的表连接操作可能会影响数据库的性能。特别是在处理大量数据时，表连接操作可能会成为性能瓶颈。此外，为了维护外键约束和确保数据的一致性，可能需要额外的计算和存储资源。过度规范化可能导致不实用：
在某些业务场景中，过度规范化可能不符合实际需求。例如，在数据仓库设计中，可能会故意违反第三范式，以便更快地进行数据查询和分析。因此，在实际应用中，需要在规范化和性能之间进行权衡。
巴斯-科德范式(BCNF):
建立在第三范式的基础上， 满足BCNF的关键在于确保关系模式（即表）中的每个非主属性都完全依赖于该关系模式的某个候选键，且不存在部分依赖和传递依赖,可以减少数据冗余和更新异常，但也可能导致查询效率下降。
部分依赖：比如说：C可以通过AB得到，并且C也可以仅通过A得到，仅通过B得到， 那么就说C部分依赖AB。
完全依赖：比如说：C可以通过AB得到，并且C不可以仅通过A得到，也不可以仅通过B得到， 那么就说C完全依赖AB。
传递依赖：比如说：B可以通过A得到，C可以通过B得到，那么就称C传递依赖A。
反范式：
两个相关连的表把主表常用的一个字段跟主键一起放到外表上这样可以方便查询
优点
- 提高查询性能：
- 反范式通过减少查询时的表关联和数据查找步骤，可以显著提高查询性能。
- 特别是针对经常需要进行联结操作的表，反范式可以避免频繁的联结操作，降低数据库的负载。
- 减少数据关联：
- 在正常的范式化数据库中，数据被拆分成多个表，表之间可能存在复杂的关联。
- 反范式通过数据冗余来消除这些关联，使得读取数据更加快速和简单，减少了错误发生的机会。
- 简化查询语句：
- 使用反范式技术，可以大大简化复杂的查询语句。
- 数据冗余使得查询只需在单个表中进行，不再需要联结多个表，提高了查询语句的可读性和易用性。
缺点
- 数据冗余：
- 反范式增加了数据冗余，这可能导致数据的不一致性。
- 当修改了冗余数据的一份副本而忘记更新其他副本时，数据会出现不一致的情况。
- 存储空间浪费：
- 由于冗余数据的存在，反范式会导致存储空间的浪费。
- 每个冗余数据副本都需要占用额外的存储空间，当数据量大时，可能造成严重的空间浪费。
- 更新操作复杂：
- 反范式增加了数据冗余，因此当需要更新数据时，必须同时更新所有相关的冗余数据。
- 这增加了更新操作的复杂度，并且容易出错。
- 数据删除风险：
- 表格内的冗余数据较多时，在删除某些数据时，可能会造成表中一些有用的信息丢失。
MySQL的工作原理
当客户端通过链路成功连接到MySQL服务器时，MySQL的连接管理模块会负责处理这一连接请求，允许客户端通过默认的3306端口进行通信，并且默认支持最多1000个并发连接。一旦连接建立，MySQL服务器便以服务的方式运行起来。
随后，客户端发送的SQL语句会被MySQL的分析器接收，分析器会对这些语句进行严格的语法检查。如果语句存在语法错误，分析器会立即将错误信息反馈给客户端。若语句语法正确，分析器会进一步生成执行计划，该计划详细描述了如何执行这条SQL语句。在这个过程中，MySQL会考虑SQL语句的结构特点，比如连表查询中的括号优先级，以及是否可以利用索引来加速查询。通过EXPLAIN命令，我们可以直观地查看这个执行计划。
在执行SQL语句之前，MySQL还会进行权限检查，确保客户端拥有执行该语句的权限。如果权限不足，MySQL会返回相应的错误消息。
值得注意的是，在MySQL 8.0之前的版本中，如果执行的是查询语句，MySQL会先尝试从查询缓存中获取结果。然而，从MySQL 8.0开始，这个功能已经被移除，因为在实际应用中，查询缓存的效果并不理想。
接下来，执行器会根据执行计划来执行SQL语句。在执行过程中，MySQL会进行各种查询优化操作，以提高查询效率。这些优化操作可能包括选择合适的索引、调整查询顺序等。
最终，数据操作会涉及到底层的存储引擎。MySQL支持多种存储引擎，如InnoDB、MyISAM等，它们负责在磁盘上存储和检索数据。每个表的数据通常都存储在MySQL文件目录下的data目录中。
当SQL语句执行完毕后，执行结果会通过之前建立的连接被返回给客户端。这样，客户端就可以根据返回的结果进行后续处理。
