就数据库层面而言，当前任何隔离级别下都不会发生丢失更新的问题，以 InnoDB 存储引擎为例，如果你想要更改表中某行数据，该行数据上必然会加上 X 锁，而对应的表上则会加上 IX 锁，其他任何事务都必须等待获取该锁才能进行修改操作。
五、数据库设计范式数据库设计当中常用的三范式如下：
第一范式：属性不可分要求表中的每一列都是不可再细分的原子项。这是最低的范式要求，通常都能够被满足。
第二范式：属性完全依赖于主键要求非主键列必须完全依赖于主键列，而不能存在部分依赖。示例如下：
mechanism_id （组织机构代码） employee_id （雇员编号） ename （雇员名称） mname （机构名称）28193182 10001 heibaiying XXXX公司
以上是一张全市在职人员统计表，主键为：机构编码 + 雇员编号。表中的雇员名称完全依赖于此联合主键，但机构名称却只依赖于机构编码，这就是部分依赖，因此违背了第二范式。此时常用的解决方式是建立一张组织机构与组织名称的字典表。
第三范式：避免传递依赖非主键列不能依赖于其他非主键列，如果其他非主键列又依赖于主键列，此时就出现了传递依赖。示例如下：
employee_id （雇员编号） ename （雇员名称） dept_no (部门编号) dname（部门名称）10001 heibaiying 06 开发部
以上是一张雇员表，雇员名称和所属的部门编号都依赖于主键 employee_id ，但部门名称却依赖于部门编号，此时就出现了非主键列依赖于其他非主键列，这就违背的第三范式。此时常用的解决方式是建立一张部门表用于维护部门相关的信息。
反范式设计从上面的例子中我们也可以看出，想要完全遵循三范式设计，可能需要额外增加很多表来进行维护。所以在日常开发中，基于其他因素的综合考量，可能并不会完全遵循范式设计，甚至可能违反范式设计，这就是反范式设计。
参考资料官方文档：The InnoDB Storage Engine，Optimization and Indexes，InnoDB Locking and Transaction Model
姜承尧 . MySQL技术内幕:InnoDB存储引擎(第2版) . MySQL技术内幕 . 2013-05
施瓦茨 (Baron Schwartz) / 扎伊采夫 (Peter Zaitsev) / 特卡琴科 (Vadim Tkachenko) . 高性能mysql(第3版) . 电子工业出版社 . 2013-05-01
InnoDB 数据页解析
MySQL索引背后的数据结构及算法原理
MYSQL-B+TREE索引原理
Innodb中的事务隔离级别和锁的关系
更多文章，欢迎访问 [全栈工程师手册] ，GitHub 地址：https://github.com/heibaiying/Full-Stack-Notes
