数据库锁机制

现在的系统更趋向于多节点化，所以在实际应用中肯定存在多个节点的请求对数据库中的某一条数据进行同时操作，如何处理这样的情况非常重要，在这种情况下，数据库锁机制就派上用场了。

情况一：多个事务对同一笔数据进行更新操作，每个事务均不知道其他事务的存在，最后完成的事务将完成对这条数据的修改，其他事务的修改均失效，这将导致数据错误，解决方法有两种，悲观锁和乐观锁

一.悲观锁

a.传统的悲观锁一般是在页面初始化的时候即使用select ****** for update nowait将数据库锁住，然后对数据操作完成后，再做提交更新并释放锁。这种方法的缺点是要长时间占用资源，在高并发量的情况下，想获得性能上的提升就非常困难了。

b.现在的悲观锁也是使用for update nowait语句，但是执行数据库锁的时机是在用户提交数据更新时，在保证这条数据没有变化的前提下，再对这条数据进行更新处理。如果这条数据跟当初操作时发生了变化，则不进行更新并告知客户。

二.乐观锁

a.旧值条件法，就是在更新数据的时候使用旧的值作为查询条件，例如有个人员信息表（person）要将年龄字段（age）从20修改成30，则可以使用如下语句：update person set age = 30 where age = 20；如果这条记录在更新之前已经被其他人操作过了，例如年龄已经改成了25，则会记录本次更新了0行，然后页面上会再提示用户重新修改。这种方法的风险是，假如其他模块使用了悲观锁来锁定了这条数据，那么此次操作只能进行等待，造成阻塞。

b.版本列法，就是在数据库中对表多加上一列来进行标识，先查询到版本号version，然后设置update语句的筛选条件为version+1，如果不满足此条件，则证明此数据已被操作，在进行数据更新时，也需要将此字段进行同步更新，保证其他人获取到的数据也是最新的。

情况二：有两个事务，一个为更新，一个为查询，当更新事务未提交更新时，查询事务读取的均为临时数据，则会产生脏读情况，此方法的解决方法也很简单，在更新事务未提交事务之前，查询事务不允许查询其操作的值。

情况三：这是情况二的升级版本，查询事务进行多次查询，由于更新事务未提交，则每次查询到的数据均不同，此时发生不可重复读，只要查询事务在更新事务提交后进行操作，则此情况可以避免。

情况四：有两个事务，一个为查询，一个为插入，假如我需要查询某一个条件的数据条数，在未进行插入事务前，结果集为10条，然后我插入了一条数据，实际结果集则为11条，此时则发生幻想读，只需要在查询时，不要进行任何插入操作即可。

转载于:https://my.oschina.net/u/2296601/blog/665866