MySQL - for update 行锁 表锁

for update 的作用是在查询的时候为行加上排它锁，当一个事务的 *** 作未完成时候，其他事务可以读取但是不能写入或更新。

它的典型使用场景是 高并发并且对于数据的准确性有很高要求 ，比如金钱、库存等，一般这种 *** 作都是很长一串并且开启事务的，假如现在要对库存进行 *** 作，在刚开始读的时候是1，然后马上另外一个进程将库存更新为0了，但事务还没结束，会一直用1进行后续的逻辑，就会有问题，所以需要用for upate 加锁防止出错。

行锁的具体实现算法有三种：record lock、gap lock以及next-key lock。

只在可重复读或以上隔离级别下的特定 *** 作才会取得 gap lock 或 next-key lock，在 Select、Update 和 Delete 时，除了基于唯一索引的查询之外，其它索引查询时都会获取 gap lock 或 next-key lock，即锁住其扫描的范围。主键索引也属于唯一索引，所以主键索引是不会使用 gap lock 或 next-key lock

for update 仅适用于InnoDB，并且必须开启事务，在begin与commit之间才生效。

select 语句默认不获取任何锁，所以是可以读被其它事务持有排它锁的数据的！

InnoDB 既实现了行锁，也实现了表锁。

当有明确指定的主键/索引时候，是行级锁，否则是表级锁

假设表 user，存在有id跟name字段，id是主键，有5条数据。

明确指定主键，并且有此记录，行级锁

无主键/索引，表级锁

主键/索引不明确，表级锁

明确指定主键/索引，若查无此记录，无锁

参考博文：

https://segon.cn/mysql-for-update.html

当 web 日志中出现行锁超时错误后，很多开发都会找我来排查问题，这里说下问题定位的难点！

1. MySQL 本身不会主动记录行锁等待的相关信息，所以无法有效的进行事后分析。

2. 锁争用原因有多种，很难在事后判断到底是哪一类问题场景，尤其是事后无法复现问题的时候。

3. 找到问题 SQL 后，开发无法有效从代码中挖掘出完整的事务，这也和公司框架-产品-项目的架构有关，需要靠 DBA 事后采集完整的事务 SQL 才可以进行分析。

FOR UPDATE 是一种行级锁，又叫排它锁。仅适用于 InnoDB ，并且必须开启事务，在 BEGIN 与 COMMIT 之间才生效。

开启两个 MySQL 命令窗口

当 命令窗口1 执行完 SELECT ... FOR UPDATE 后（此时事务还未结束）， 命令窗口2 执行 SELECT ... FOR UPDATE 语句时将会阻塞在那，直到 命令窗口1 中的事务结束（执行完 COMMIT ）。

其中一个使用场景是用于修改订单状态，修改订单状态往往需要两个步骤：

当有两个任务同时请求时，有可能出现如下情况：

其中，任务B将订单状态改为3的前提是订单状态为1，但是上述情况下任务B修改订单时订单状态已变成2了，并不符合预期，通过 SELECT ... FRO UPDATE 就可以解决上述问题。

---