多事务并发更新同一字段，引入锁

并发更改引发的问题

注意下面的例子：

事务1	事务2
BEGIN;	BEGIN;
SELECT data FROM test WHERE id = 1;
得到 AB	SELECT data FROM test WHERE id = 1;
	得到 AB
UPDATE test SET data = ‘CB’ WHERE id = 1;
	UPDATE test SET data = ‘AD’ WHERE id = 1;
	等待事务1
COMMIT;	等待事务1
	COMMIT;
SELECT data FROM test WHERE id = 1;
得到 AD

看到什么问题没？显然，事务1的更改被覆盖了。

解决方法

悲观锁

当我们要对表中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制，先锁定再修改的方式被称为悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）。

举例如下：

事务1	事务2
BEGIN;	BEGIN;
SELECT data FROM test WHERE id = 1 FOR UPDATE;
得到 AB	SELECT data FROM test WHERE id = 1 FOR UPDATE;
	等待事务1
UPDATE test SET data = ‘CB’ WHERE id = 1;	等待事务1
	等待事务1
COMMIT;	等待事务1
	得到 CB

乐观锁

乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回给用户错误的信息，让用户决定如何去做。乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。

举例如下：

事务1	事务2
BEGIN;	BEGIN;
SELECT data FROM test WHERE id = 1;
得到 AB	SELECT data FROM test WHERE id = 1;
	得到 AB
UPDATE test SET data = ‘CB’ WHERE id = 1 AND data = ‘AB’;
	UPDATE test SET data = ‘AD’ WHERE id = 1 AND data = ‘AB’;
	等待事务1
COMMIT;	等待事务1
	COMMIT;
SELECT data FROM test WHERE id = 1;
得到 CB

显然，事务1更新成功，事务2实际上是更新失败的，可以尝试再次更新。

总结

• 乐观锁并未真正加锁，效率高。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。

• 悲观锁依赖数据库锁，效率低。但是更新失败的概率比较低。