数据不一致的原因
数据冗馀、不正确的并发控制、故障和错误。
数据库三范式
1 )第一范式)确保各列保持原子性
2 )第二范式：确认表中各列与主键相关
3 )第三范式：确保各列与主键直接相关，而不是间接
事务处理特性
事务是并发控制的单位，是一组用户定义的操作，其特征是以begin transaction开始，以commit或rollback结束。
1 )原子性)事务中的操作是全部还是不全部
2 )一致性：事务的结果是数据库从一个一致性状态更改为另一个一致性状态
3 )隔离性)一个事务的执行不能被其他事务干扰
4 )持久性/持久性：提交事务后，对数据库的更改将是永久的
事务的四个隔离级别
数据库事务的隔离级别有四种：读取未确认、读取已确认、可删除读取和序列化。 此外，事务并发操作可能会导致脏读，不能重复读取、幻读。 通过实例逐一阐述这些概念和联系。
已读取未确认
读取未提交的数据，顾名思义，就是一个事务读取另一个未提交的事务的数据。
事例：上司向程序员支付工资。 程序员的工资为3.6万/月。 但是，发薪日上司错误地按了数字，变成了3.9万/月。 那笔钱转到了程序员的账户上，但事务还没有交。 那时，程序员去查了自己这个月的工资，比平时多了三千元，觉得涨了工资，很高兴。 但是，上司很快就意识到了错误，马上将差点提交的事务回滚，将数字改为3.6万后提交。
分析：实际程序员这个月的工资还是3.6万，但程序员看到的是3.9万。 他看到的是上司还没有提交事务时的数据。 这是肮脏的读法。
怎么解决不洁的读法？ 领先优势！ 可以提出来解决不洁的读书问题。
已完成确认
读提交顾名思义，就是一个事务等待另一个事务提交，然后再读取数据。
事例：程序员拿着信用卡去享受生活。 (卡里当然只有3.6万。 他埋单的时候)程序员事务接通时，资费系统事先检测出他卡里有3.6万。 就是这个时候。 程序员的妻子必须把钱全部拿出来供家庭用。 收费系统准备取现时，重新检查卡上的金额，发现钱不见了。 (第二次检查金额当然要等妻子转出金额事务提交完毕。 程序员会变得忧郁。 明明卡里有钱……
分析：这就是领先提交。 如果存在要更新(UPDATE )数据的事务，则在提交此更新操作事务之前，读事务无法读取数据。 可以解决脏领导的问题。 但是，在此实例中，一个事务范围内的两个相同查询返回不同的数据。 这是不能重复阅读的。
怎么解决不可再现的问题？ 可重复读取！
d-color:rgb(255,255,255);">Repeatable read
重复读，就是在开始读取数据（事务开启）时，不再允许修改操作
事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（事务开启，不允许其他事务的UPDATE修改操作），收费系统事先检测到他的卡里有3.6万。这个时候鲤鱼香水不能转出金额了。接下来收费系统就可以扣款了。
分析：重复读可以解决不可重复读问题。写到这里，应该明白的一点就是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。
什么时候会出现幻读？
事例：程序员某一天去消费，花了2千元，然后鲤鱼香水去查看他今天的消费记录（全表扫描FTS，妻子事务开启），看到确实是花了2千元，就在这个时候，程序员花了1万买了一部电脑，即新增INSERT了一条消费记录，并提交。当妻子打印程序员的消费记录清单时（妻子事务提交），发现花了1.2万元，似乎出现了幻觉，这就是幻读。
那怎么解决幻读问题？Serializable！
Serializable 序列化
Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。
数据库锁
1）独占锁（排它锁）：用于修改
2）共享锁：只读
3）更新锁：用于可更新的资源中，防止死锁