Mybatis 如何使用 Mysql 悲观锁，求解答

悲观锁就是数据库里面锁住 类似for update查询

创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都做网站、网站设计、外贸营销网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的北票网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

乐观锁不是在数据库端锁住的

而是程序控制的

你说的那Mybatis我不知道是什么

但是乐观锁一般是这样

比如你数据库中有一条记录

你可以给他加上一个版本号

这样

如果同时有2个人查询出那个数据要修改

第一个人先查出来有事走了

第二个人查出来给改了

这时候你看

第一个人查出来的数据版本号比如是1

第二个人查出来也是1 但是他改了数据以后版本号变成2

这时候第一个人回来了继续修改数据

他的版本号是1 比2低

这时候就告诉他数据过期

乐观锁大概就是这个意思

是一种思路！

mysql事务隔离级别 以及 悲观锁-乐观锁

以上不是重点，重点是 对事务控制语句不熟悉。

SAVEPOINT identifier : 在事务中 创建保存点。一个事务中 允许有多个保存点。

RELEASE SAVEPOINT identifier : 删除保存点。当事务中 没有指定的 保存点，执行该语句 会抛异常。

ROLLBACK TO identifier : 把事务回滚到 保存点。

Say you have a table T with a column C with one row in it, say it has the value '1'. And consider you have a simple task like following:

That is a simple task that issue two reads from table T, with a delay of 1 minute between them.

If you follow the logic above you can quickly realize that SERIALIZABLE transactions, while they may make life easy for you, are always completely blocking every possible concurrent operation, since they require that nobody can modify, delete nor insert any row. The default transaction isolation level of the .Net System.Transactions scope is serializable, and this usually explains the abysmal performance that results.

在Repeatable Read隔离级别下，一个事务可能会遇到幻读（Phantom Read）的问题。

幻读是指，在一个事务中，第一次查询某条记录，发现没有，但是，当试图更新这条不存在的记录时，竟然能成功，并且，再次读取同一条记录，它就神奇地出现了。

我们仍然先准备好students表的数据：

然后，分别开启两个MySQL客户端连接，按顺序依次执行事务A和事务B：

事务B在第3步第一次读取id=99的记录时，读到的记录为空，说明不存在id=99的记录。随后，事务A在第4步插入了一条id=99的记录并提交。事务B在第6步再次读取id=99的记录时，读到的记录仍然为空，但是，事务B在第7步试图更新这条不存在的记录时，竟然成功了，并且，事务B在第8步再次读取id=99的记录时，记录出现了。

可见，幻读就是没有读到的记录，以为不存在，但其实是可以更新成功的，并且，更新成功后，再次读取，就出现了。

在冲突较少的情况下，使用乐观锁。乐观锁 因为没有 加锁 释放锁，也减少了 加锁 释放锁的开销。

冲突较多时，如果使用乐观锁 需要不停地尝试，所以 使用悲观锁。

如果乐观锁 进行尝试时 的花销较大，也是使用悲观锁。

mysql 悲观锁 没有锁定 什么原因

mysql 悲观锁 没有锁定 的原因主要是事务控制不严谨。

悲观锁指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

举例说明：

可以使用命令设置MySQL为非autocommit模式：

set autocommit=0;

设置完autocommit后，就可以执行系统的正常业务了。

具体如下：

//0.开始事务

begin;

1.查询出商品信息

select status from t_goods where id=1 for update; 在此使用了select…for update的方式，这样就通过数据库实现了悲观锁。

2.根据商品信息生成订单

insert into t_orders (id,goods_id) values (null,1);

3.修改商品status为2

update t_goods set status=2;

4.提交事务

commit;

注：上面的begin/commit为事务的开始和结束，因为在前一步关闭了mysql的autocommit，所以需要手动控制事务的提交。

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、不具体的主键值为查询条件

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

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，此时事务二就会操作失败，从而保证了数据的正确性。

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

分享名称：mysql悲观锁怎么开 医用腿部按摩器气囊
当前链接：http://azwzsj.com/article/dopjhsp.html