最近做一个统计；需要把一个字段(存放数据是json)里某一个数字加1 然后在修改该字段；当时就那么一写最后发现该数据和明细对不上； 其实这个应该是并发引起的，先select 在update 这样写其实会出现一些问题

###第一种解决方案

事务，即用一个事务来包裹上面的SELECT+UPDATE操作+写共享锁。

读共享锁是通过下面这样的SQL获得的：SELECT * FROM parent WHERE NAME = 'Jones' LOCK IN SHARE MODE;

如果事务A获得了先获得了读共享锁，那么事务B之后仍然可以读取加了读共享锁的行数据，但必须等事务A commit或者roll back之后才可以更新或者删除加了读共享锁的行数据。

如果事务A先获得了某行的写共享锁，那么事务B就必须等待事务A commit或者roll back之后才可以访问行数据。

SELECT counter_field FROM child_codes FOR UPDATE;UPDATE child_codes SET counter_field = counter_field + 1;

###第二种解决方案

乐观锁,上面是一种观锁机制，而且SELECT...FOR UPDATE方式也不太常用

SELECT counter_field FROM child_codes FOR UPDATE;UPDATE child_codes SET counter_field = counter_field + 1 WHERE counter_field='上面select出来的值' ;

这样可以根据UPDATE返回值来判断是否更新成功，如果返回值是0则表明存在并发更新，那么只需要重试一下就好了。

1. 如果对读的响应度要求非常高，比如证券交易系统，那么适合用乐观锁，因为悲观锁会阻塞读

2. 如果读远多于写，那么也适合用乐观锁，因为用悲观锁会导致大量读被少量的写阻塞

3. 如果写操作频繁并且冲突比例很高，那么适合用悲观写独占锁