mysql的乐观锁与悲观锁

乐观锁

总是认为不会产生并发问题，每次去取数据的时候总认为不会有其他线程对数据进行修改，因此不会上锁，但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS操作实现。

例如：

有这样一个表：

每次更新时update在条件后再附加一个时间为条件：

update user_info set password='somelog' where username='somelog' and time='2018-07-11';

　　

因为如果并发操作，同一刻查询的时间一样，但是先插入时将时间更改，那么后更新的操作就不能进行，因为time的值被前一个操作更改了。

这就是乐观锁的实现原理，更新时附加一个版本号。

 

悲观锁

总是假设最坏的情况，每次取数据时都认为其他线程会修改，所以都会加锁（读锁、写锁、行锁等），当其他线程想要访问数据时，都需要阻塞挂起。可以依靠数据库实现，如行锁、读锁和写锁等，都是在操作之前加锁，在Java中，synchronized的思想也是悲观锁。
注：要使用数据库的悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。

悲观锁分为两种：共享锁和排它锁

共享锁是其它事务可以读但是不能写
排他锁是只有自己得事务有权限对此数据进行读写

 

SQL写法
共享锁（S）：

SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE;

排他锁（X)：

SELECT * FROM table_name WHERE ... FOR UPDATE;

加锁必须先开启事务：begin;（开启事务）->加锁、操作->commit;（提交事务，归还锁）

 

加锁分为显式加锁与隐式加锁，上面的写法是显式加锁。mysql在执行insert、update会自动加锁，mysql对select却不会加锁。

 例如：

不加锁

select * from data where username=‘somelog’;

加排它锁：

select * from data where username=‘somelog’ for update;

如果一个事务加了排它锁之后，另外一个事务不加锁的select也可以查询到数据

以上可以看出，锁不是针对事务的，排它锁只有一把，谁拿了谁就可以进行更新，但是没有拿到锁的事务只要在select不加上排它锁也可以查询到数据。