mysql中的乐观锁和悲观锁怎么用

关于mysql中的乐观锁和悲观锁面试的时候被问到的概率还是比较大的。

mysql的悲观锁：

其实理解起来非常简单，当数据被外界修改持保守态度，包括自身系统当前的其他事务，以及来自外部系统的事务处理，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制，但是也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在自身系统中实现了加锁机制，也无法保证外部系统不会修改数据。

来点实际的，当我们使用悲观锁的时候我们首先必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新 *** 作后，MySQL会立刻将结果进行提交。

关闭命令为：set autocommit=0

悲观锁可以使用select…for update实现，在执行的时候会锁定数据，虽然会锁定数据，但是不影响其他事务的普通查询使用。此处说普通查询就是平时我们用的：select * from table 语句。在我们使用悲观锁的时候事务中的语句例如：

//开始事务

begin/begin work/start transaction(三选一)

//查询信息

select * from order where id=1 for update

//修改信息

update order set name='names'

//提交事务

commit/commit work(二选一)

此处的查询语句for update关键字，在事务中只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一条数据时会等待其它事务结束后才执行，一般的SELECT查询则不受影响。

执行事务时关键字select…for update会锁定数据，防止其他事务更改数据。但是锁定数据也是有规则的。

查询条件与锁定范围：

1、具体的主键值为查询条件

比如查询条件为主键ID=1等等，如果此条数据存在，则锁定当前行数据，如果不存在，则不锁定。

2、不具体的主键值为查询条件

比如查询条件为主键ID>1等等，此时会锁定整张数据表。

3、查询条件中无主键

会锁定整张数据表。

4、如果查询条件中使用了索引为查询条件

明确指定索引并且查到，则锁定整条数据。如果找不到指定索引数据，则不加锁。

悲观锁的确保了数据的安全性，在数据被 *** 作的时候锁定数据不被访问，但是这样会带来很大的性能问题。因此悲观锁在实际开发中使用是相对比较少的。

mysql的乐观锁：

相对悲观锁而言，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会对数据的冲突与否进行检测，如果发现冲突，则让返回用户错误的信息，让用户决定如何去做。

一般来说，实现乐观锁的方法是在数据表中增加一个version字段，每当数据更新的时候这个字段执行加1 *** 作。这样当数据更改的时候，另外一个事务访问此条数据进行更改的话就会 *** 作失败，从而避免了并发 *** 作错误。当然，还可以将version字段改为时间戳，不过原理都是一样的。

例如有表student，字段：

id,name,version

1 a 1

当事务一进行更新 *** 作：update student set name='ygz' where id = #{id} and version = #{version}

此时 *** 作完后数据会变为id = 1,name = ygz,version = 2，当另外一个事务二同样执行更新 *** 作的时候，却发现version != 1，此时事务二就会 *** 作失败，从而保证了数据的正确性。

悲观锁和乐观锁都是要根据具体业务来选择使用，本文仅作简单介绍。

乐观锁一开始也说了，就是一开始假设不会造成数据冲突，在最后提交的时候再进行数据冲突检测。在乐观锁中，我们有3种

常用的做法来实现。

[1]第一种就是在数据取得的时候把整个数据都copy到应用中，在进行提交的时候比对当前数据库中的数据和开始的时候更新前取得的数据。当发现两个数据一模一样以后，就表示没有冲突可以提交，否则则是并发冲突，需要去用业务逻辑进行解决。

[2]第二种乐观锁的做法就是采用版本戳，这个在Hibernate中得到了使用。采用版本戳的话，首先需要在你有乐观锁的数据库table上建立一个新的column，比如为number型，当你数据每更新一次的时候，版本数就会往上增加1。比如同样有2个session同样对某条数据进行 *** 作。两者都取到当前的数据的版本号为1，当第一个session进行数据更新后，在提交的时候查看到当前数据的版本还为1，和自己一开始取到的版本相同。就正式提交，然后把版本号增加1，这个时候当前数据的版本为2。当第二个session也更新了数据提交的时候，发现数据库中版本为2，和一开始这个session取到的版本号不一致，就知道别人更新过此条数据，这个

时候再进行业务处理，比如整个Transaction都Rollback等等 *** 作。在用版本戳的时候，可以在应用程序侧使用版本戳的验证，也可以在数据库侧采用Trigger(触发器)来进行验证。不过数据库的Trigger的性能开销还是比较的大，所以能在应用侧进行验证的话还是推荐不用Trigger。

[3]第三种做法和第二种做法有点类似，就是也新增一个Table的Column，不过这次这个column是采用timestamp型，存储数据最后更新的时间。在Oracle9i以后可以采用新的数据类型，也就是timestamp with time zone类型来做时间戳。这种Timestamp的数据精度在Oracle的时间类型中是最高的，精确到微秒(还没与到纳秒的级别)，一般来说，加上数据库处理时间和人的思考动作时间，微秒级别是非常非常够了，其实只要精确到毫秒甚至秒都应该没有什么问题。和刚才的版本戳类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。如果不想把代码写在程序中或者由于别的原因无法把代码写在现有的程序中，也可以把这个时间戳乐观锁逻辑写在Trigger或者存储过程中。

悲观锁和乐观锁定义：

乐观锁：乐观锁在 *** 作数据时非常乐观，认为别人不会同时修改数据。因此乐观锁不会上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：如果别人修改了数据则放弃 *** 作，否则执行 *** 作。

悲观锁：悲观锁在 *** 作数据时比较悲观，认为别人会同时修改数据。因此 *** 作数据时直接把数据锁住，直到 *** 作完成后才会释放锁；上锁期间其他人不能修改数据。

悲观锁实现方式

悲观锁的实现，往往依靠数据库提供的锁机制。在数据库中，悲观锁的流程如下：

1.在对记录进行修改之前，先尝试为该记录加上排它锁(exclusive locking)。

2.如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。

3.如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。

4.期间如果有其他对该记录做修改或加排它锁的 *** 作，都会等待解锁或直接抛出异常。

---