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的记录时，记录出现了。

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

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

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

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

乐观锁就是认为不会产生数据访问冲突。比如update

修改商品status为2

update t_goods

set status=2,version=version+1

where id=#{id} and version=#{version}

---