前言
MySQL更新记录，都知道怎么操作的，但是有没有想过并发update操作，会不会同时修改呢？也就是update操作会不会自动加锁？其实，update更新的时候会加锁的，所以在处理并发请求的，也经常用乐观锁（版本号、状态）进行判断，update操作自动加锁有两种情况：
- MySQL5.5版本以后默认用InnoDB存储引擎，并且采用可重复读的隔离级别，在进行update操作会进行加锁的！！！
- 如果涉及到索引查询则会加行锁，如果需要查整个表，则会加间隙锁（全部锁）。
案例分析
接下来用实际案例update操作是会自动加锁的，案例场景：每个福利码只能兑换一次，兑换库存，防止库存溢出。那么这里就可以在Update更新的时候，增加一个判断，比如库存必须大于0，如果update操作会自动加锁，每次请求则会阻塞其他请求。
其中一个线程A开启事务进行兑换id = 2 的福利码，库存剩余 1
代码语言：sql复制set autocommit=0; BEGIN;
update koc_reward set remain_num = remain_num - 1 where id =2 and remain_num > 0;
COMMIT; 这时候模拟，另一个线程B也进来查询，并兑换，也是同样调用Update语句
代码语言：sql复制update cz_koc_reward set remain_num = remain_num - 1 where id =2 and remain_num > 0; 最终结果：
线程A事务还没提交的，线程B也对改福利码进行扣库存操作，就会被阻塞，直到线程A提交了，可以看到线程B在阻塞着
A线程提交事务，线程B才继续执行，此时库存已经没了，线程B就会更新 0 行，说明库存大于 0 的数据已经没有了
总结
update更新流程。会先去查询where 条件的数据，然后修改数据，在二阶段进行提交
所以，在更新的时候，增加库存校验，或者其他版本号字段校验，其实就可以实现，乐观锁 版本号防止库存超卖溢出等情况。上面案例where 除了 id主键，还额外加了 remain_num > 0 ，也就是其他线程执行的时候都会查询 remain_num > 0 的数据。如果去掉remain_num > 0 的话，线程B执行虽然也会加锁，但是依然会查询id = 2的数据，然后直接扣减remain_num。就会导致库存溢出。
我正在参与2023腾讯技术创作特训营第四期有奖征文，快来和我瓜分大奖！
