悲观锁(Pessimistic Lock)
悲观锁(Pessimistic Lock), 顾名思义，便是很悲观，每次去拿数据的时候都认为别人会修正，以是每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
最常用的便是 select … for update，它是一种行锁，会把select出来的结果行锁住，在本事务提交或者回滚之前，不许可其他事务对这些行做update、delete、for update操作。
乐不雅观锁(Optimistic Lock)
乐不雅观锁(Optimistic Lock), 顾名思义，便是很乐不雅观，每次去拿数据的时候都认为别人不会修正，以是不会上锁，期间该数据可以随便被其他人读取，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以利用版本号等机制。
版本号机制是乐不雅观锁最常用的办法，便是在表中增加一个版本号的字段，更新前先查一遍获取版本号，再作为更新语句的where条件进行更新，如果数据在获取版本号之后，在更新之前已经改变了，那就会更新失落败，由于末了更新了0条数据，PHP后台拿到更新数如果为0，则解释更新失落败，涌现了并发问题，然后做详细的处理。
例如有两个人同时对某条数据做修正，过程如下：
操作员A操作如下：
select id, balance, version from table where id=“1”;
查询结果：id=1, balance=1000, version=1
update table set balance=balance+100, version=version+1 where id=“1” and version=1;
实行后，返回的更新结果是1，解释更新了一条，数据库里的结果是：id=1, balance=1100, version=2
操作员B操作如下：
select id, balance, version from table where id=“1”;
查询结果：id=1, balance=1000, version=1, 解释操作员A还没修正。
update table set balance=balance-50, version=version+1 where id=“1” and version=1 ;
查的时候，操作员A还没修正，当要更新时，操作员A已经先修正成功，以是数据库里实际值是id=1, balance=1100, version=2，
操作员B也将版本号加一(version=2)试图向数据库提交数据(balance=950)，但此时查不到where id=“1” and version=1 的数据，
以是update就失落败了，实行结果是0，解释没有对任何数据更新成功。
现在再去查一下，结果还是操作员A操作完成之后的结果
select id, balance, version from table where id=“1”;
查询结果：id=1, balance=1100, version=2
以上是自己实现版本号机制的事理，真正利用的版本号机制是数据库本身带有的机制，一旦创造更新的版本号不是最新的就会被驳回
