MySQL数据库的四大特征、四大隔离级别、三大范式

一、数据概念

在数据库系统中，多个事务并发执行时，针对数据库不同的隔离级别，可能会出现一些问题。可能出现的问题主要有：脏读，不可重复读，幻读。

1、脏读的现象

假设A和B两个事务都出现了并发，A事务先开始读TMP数据表中的数据，然后再更新TMP数据表中的数据，A事务还没提交，这时刚好B事务开始，然后也需要读TMP数据表，这时得到的是刚才A事务更新后的数据，如果接下来A事务真的提交了，那么这个数据还算理想，实际上还有其他事务的更新出现，这里暂不考虑，但是如果接下来A事务回滚了，那么B事务刚才读到的数据，是不是就没有价值了，等于是垃圾数据了，所以我们把这种现象称之为脏读。

2、不可重复读的现象

 

假设A和B两个事务出现了并发，A事务先读TMP表中的数据，没有进行提交，然后B事务更新了TMP表中的数据，接着A事务又读了一次TMP表中的数据，但发现两次数据不一样了，这个结果就使A事务接下来的处理无所适从了，因为基础数据不一样了，概括来说，就是你不能重复读同一个数据，如果重复读的话，有可能返回不一样的结果，我们将这种现象称之为不可重复读。

3、幻读的现象

 

A事务读了一次TMP表，得到最后的ID是3，B事务也同样读了一次，得到最后的ID也是3，接下来A事务先插入了一行，然后读了一下最新的ID是4，刚好是前面ID3+1，然后B事务也插入了一行，接着读了一下最新的ID，发现是5，而不是之前的3+1，我们发现，在使用ID做判断或做关键数据时，就会出现问题，这让B事务的感觉产生了幻觉一样，得到了意想不到的情况，所以叫幻读；其实还有删除数据，修改数据，也会有类似的情况发生。

二、数据库的隔离级别

为了解决这些问题，MySQL数据库为事务设立了四个隔离级别，分别是读未提交、读已提交、可重复读、可串行化。这四个隔离级别在隔离度上以及对性能影响上有哪些不同，这样我们就可以更好地使用事务，做到理想的配置了。

 

读未提交（Read uncommitted）这个隔离级别是最低级别的，隔离度最弱，脏读、不可重复读、幻读，这三种现象都可能发生，所以这种级别是理论上的存在，实际项目中没有人使用，但是性能最高。

读已提交（Read committed）这个隔离级别解决了脏读问题，但仍然存在不可重复读和幻读的可能。

可重复读（Repeatable read）这个隔离级别，仅存在一定的幻读可能，其他两种现象都已经解决了，这个也是MySQL数据库默认的隔离级别。

可串行化（Serializable）这个隔离级别是最高级别的，三种不想发生的现象都已经解决了，事务A操作数据库时，事务B只能排队等待，因此性能也最低。

三、事务的四大特征

1、事务的原子性

事务包含的所有数据库操作，要么全部都成功，要么全部都失败，不可以分开执行

 

2、事务的一致性

虽然将一个大事务要完成的任务拆分成若干个小事务了，但这些小事务完成的数据状态与使用一个大事务完成后的数据状态是一致的

 

3、事务的隔离性

通常一个事务的执行不会被另一个事务干扰，但这只是一个概况性描述，具体隔离程度取决于使用的隔离度级别

 

4、事务的持久性

它是事务的终极保证，事务终结的标志，内存的数据以及持久化到磁盘文件中，这个也没有违背持久性特征，只是有时将单次持久化动作变成了多次持久化动作

 

四、数据库设计的三大范式

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。

在实际开发中最为常见的设计范式有三个：

1．第一范式(确保每列保持原子性)

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。

 

上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。

2．第二范式(确保表中的每列都和主键相关)

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。

 

订单信息表

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。

 

这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。

3．第三范式(确保每列都和主键列直接相关,而不是间接相关)

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

 

这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。