MySQL事务处理问题的正确解决

如果你研究到库存系统的开发问题时，你就会从这里出发考虑了一些有关库存信息中需要的操作和，一般的情况下会遇到的MySQL事务处理问题。特别是关于数据表锁定问题，一旦出现并发现象的时候，我们如何保证数据的完整性，值得我们考虑。

事务操作，要保证的三个原则性：

原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全部执行，要么全都不执行；

一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态；

隔离性（ISOLation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行；

持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

于是，我们假设两个对象A和B

并发对象A 和B

初始状态数据表查询结果:

事务开始的顺序 A->B

A：开始事务

此刻没有提交进行commit

在此状态下B开始了自己的MySQL事务处理：

显然，在A没有进行Commit行为的时候，B的事务中的动作无法完成，一直处于事务等待阶段，前提是在没有超出时限，B的动作无法提交。

此刻，如果A进行Commit:

此刻 B的动作中，由等待的

转变到

说明A完成事务开始解锁，B事务可以进行，但是此刻B事务没有提交（Commit）

注意：在这里我们进行两个操作，就是两个对象进行查询

A的查询：

依然存在ID为1的这项，原因是B的结果没提交，但A依旧可以读该项数据，但是数据为删除前的数据。

但是，对照B的查询：

可以知道，B对象结果已经在处理了，只是没有提交解锁。

分析可以知道，A读的是B没有提交前的结果 *** ，但B读的是自己操作的结果集，当B完成提交的时候

此刻，A的结果 ***

发现现在状态下和B的 *** 一样，A=B，这也是在理论值的范围内的。

由此，可以发现其实MySQL锁的简单性，当然，也说明当数据库进行锁操作时候，只能是写操作控制，对于读数据，往往只能访问到修改前的数据，这部分数据常常被称为”dirty”或脏数据。在现实中，我们常常是有这样的需求，当A进行写操作时候，期望B不要读数据，是对读行为的控制。

这样保证并发的时候不要出现B查的时候有，但是这个过程正好是A进行写操作的过程，虽然加锁防止并发写，但是却把对于B来说他在此过程中所看到的数据将被修改，即等A完成写操作的时候,B读的数据将被丢弃，这样说来B读到的数据应该是脏数据，或是无效数据，除非A的动作因为某些原因导致事务回滚，操作失败，这样现实数据结果和B看到的一致的时候，才断定B看到的是有效数据，而不是脏数据或是无效数据。