乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量。

相关方法：

gdb模块的链式操作提供了两个方法帮助您在SQL语句中实现“悲观锁”。可以在查询中使用LockShared方法从而在运行语句时带一把”共享锁“。共享锁可以避免被选择的行被修改直到事务提交：

此外你还可以使用LockUpdate方法。该方法用于创建锁，避免选择行被其它共享锁修改或删除：

上面这个查询等价于下面这条 SQL 语句：

FOR UPDATE 与 LOCK IN SHARE MODE 都是用于确保被选中的记录值不能被其它事务更新（上锁），两者的区别在于 LOCK IN SHARE MODE 不会阻塞其它事务读取被锁定行记录的值，而 FOR UPDATE会阻塞其他锁定性读对锁定行的读取（非锁定性读仍然可以读取这些记录，LOCK IN SHARE MODE 和 都是锁定性读）。

乐观锁，大多是基于数据版本 （ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 ““ 字段来实现。

读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行重试，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。