如果你研究到库存系统的开发问题时，你就会从这里出发考虑了一些有关库存信息中需要的操作和，一般的情况下会遇到的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看到的是有效数据，而不是脏数据或是无效数据。