我一个INSERT 还能被你 UPDATE 给卡住？

许多语言和工具都通过锁，来保证并发场景下数据和逻辑的正确性，MySQL 也不例外。除了行锁、表锁这种范围粒度外，还有这种针对读和写的 S锁共享锁和 X锁独占锁。

随着锁定范围的不同，锁与锁之间的互相影响也差异很大，这一点很好理解。比如一个操作加了表锁之后，另一个想加行锁就得等待;而一个行锁一般并不会影响锁另一行的行锁。

除了书本上和八股文，你有没有遇到过这些锁相关的问题呢？

我先来说一个最近遇到的。

现象

某天，项目出现几条监控报警，都是在写库的时候获取锁超时导致。业务会在某种特定的场景下，出现如下的 MySQL 获取锁超时，事务回滚的异常。


org.springframework.dao.CannotAcquireLockException:
### Errorupdatingdatabase.  
Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: xxx
Lockwaittimeoutexceeded; tryrestartingtransaction

看了下错误对应的日志，发现当时 MySQL 要执行一条 INSERT 操作，等了50秒超时事务回滚了。同样的代码时好时坏，那就一定和触发条件有关系了。


对应正在执行的是一个INSERT的操作
2022-xx-xx15:x:x.380 [elapse:50674] [sql:INSERTINTOxxx_table....]

按照前面的固有思路，即将执行 INSERT 的一行数据，理论上和别人没什么的冲突，为啥会拿不到锁呢？

在代码逻辑里也不能明确定位问题，只能求助 DBA 帮忙 dump 事务日志相关信息。

但内容里也没有死锁信息，事务日志里也仅有 Transaction 在等待锁的信息，像这个样子，大概看了一眼，不像死锁日志里有一个 Hold Locks 信息，这种普通的情况，具体锁在谁手里，还是两眼一抹眼。

------------------
---TRANSACTION13934594, ACTIVE41secinserting
mysqltablesinuse1, locked1
LOCKWAIT2lockstruct(s), heapsize360, 1rowlock(s), undologentries1
MySQLthreadid6695850, OSthreadhandle0x7ef74b2c0700, queryid123xxxabcupdate
INSERTINTOxxx_table(col,col1,...)
-------TRXHASBEENWAITING41SECFORTHISLOCKTOBEGRANTED:
RECORDLOCKSspaceid1057pageno3724nbits312index`xxx_id_idx`oftable`test`.`xxx_table`trxid13934594lock_modeXlocksgapbeforerecinsertintentionwaiting
Recordlock, heapno241PHYSICALRECORD: n_fields5; compactformat; infobits0
0: len8; hex800000008d8faf7d; asc        };;
1: len5; hex....123; asc12_34;;
2: len17; hex111111111111113732333338; asc111111111111111272338;;
3: len1; hex80; asc  ;;
4: len8; hex8000000000012adf; asc* ;;
------------------

没有其它办法，只好回过来仔细看事务日志。仔细看这里的 WAITING xx for this lock 下面，会提到这个等待锁的类型：

RECORDLOCKSindex`xxx_id_idx`oftable`test`.`xxx_table`lock_modeXlocksgapbeforerecinsertintentionwaiting

期中提到了

lock_modeXlocksgapbeforerecinsertintentionwaiting

是 GAP 锁，那这个间隙有多大？

再向后看，提到了索引。是因为表里的这个索引，而后面的 Recod Lock 刚好就是这个索引对应的各个字段，那对应到索引的定义，发现里面有一个字段刚好是某个业务属性的 id。

之前对事务日志不熟悉，这算一个比较重要的发现，根据这个 id 继续去查库时，发现这条记录是在前一刻刚刚写到库里。

一个刚写到库里的字段，和新的要 INSERT 的数据有什么关联呢？

此时仔细回想了一下业务逻辑，想起我们有一个异步的操作，会在数据执行之后，在某些条件下，去做更新这条记录的操作。因为这个更新操作涉及到更新多个表，还加了个事务。只是因为不是用户请求，不曾放在一起统一看过。

而我们前面的 INSERT 这个，也是在一个事务里，先执行 INSERT 再执行一个 UPDATE 的操作，可以这样理解：

会话 1先执行:

BEGIN;
1.UPDATExxx_tableSETupdate_time='xxx'WHEREid='123' ;
3.再执行一个其他操作

会话2 执行：

BEGIN;
2.INSERTINTO`xxx_table` (col1,col2)...
4.再执行一个操作

此时，我们看到两个因为锁的交叉使用，导致谁都没法完成，最终直到超时。

为什么？

那为什么一个 INSERT 会受到前面不相关的 UPDATE 操作的影响呢？

这就不得不提 MySQL 里的间隙锁（GAP Lock）。业务里的 id，就是在索引里使用到的那个，是通过某个服务生成的。而已经写入到库里的那条，id 要比我们新 INSERT 的这条，要大。GAP Lock 刚好锁定的是新写的 id 到成功写入的这条 ID。而这个写入成功的 ID，在前面正在被 UPDATE，所以两个操作就冲突了。

在线下模拟的话，可以通过 MySQL 自带的几个表，来查看锁的占用信息，可以清晰的看出来，两个操作的 lock data
是同一个数据，不冲突才怪呢。

mysql>SELECT*FROM`information_schema`.INNODB_LOCKS\G;
***************************1.row***************************
lock_id: 225753412:5845:5:253
lock_trx_id: 225753412
lock_mode: X,GAP
lock_type: RECORD
lock_table: `db`.`xxx_table`
lock_index: xxx_id_idx
lock_space: 5845
lock_page: 5
lock_rec: 253
lock_data: 3094360230, 'abc-01', '111623639', 0, 255
***************************2.row***************************
lock_id: 225751488:5845:5:253
lock_trx_id: 225751488
lock_mode: X
lock_type: RECORD
lock_table: `db`.`xxx_table`
lock_index: xxx_id_idx
lock_space: 5845
lock_page: 5
lock_rec: 253
lock_data: 3094360230, 'abc-01', '111623639', 0, 255
2rowsinset (0.04sec)

mysql>select*from`information_schema`.INNODB_LOCK_WAITS\G;
***************************1.row***************************
requesting_trx_id: 225753412//  申请资源的事务 ID
requested_lock_id: 225753412:5845:5:253
blocking_trx_id: 225751488// 阻塞的事务 ID
blocking_lock_id: 225751488:5845:5:253
1rowinset (0.04sec)

mysql>select*from`information_schema`.INNODB_TRX\G;
***************************1.row***************************
trx_id: 225751488
trx_state: LOCKWAIT
trx_started: 2022-0xxx
trx_requested_lock_id: 225851026:5874:4:1
trx_wait_started: 2022-05-2xxx
trx_weight: 3
trx_mysql_thread_id: 1875826
trx_query: insertintoxxx_tablevalues(...)
trx_operation_state: inserting
trx_tables_in_use: 1
trx_tables_locked: 1
trx_lock_structs: 2
trx_lock_memory_bytes: 360
trx_rows_locked: 1
trx_rows_modified: 1
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLEREAD
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
trx_is_read_only: 0
trx_autocommit_non_locking: 0
***************************2.row***************************
trx_id: 225753412
trx_state: RUNNING
trx_started: 2022-0xxx
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 4
trx_mysql_thread_id: 1875454
trx_query: NULL
trx_operation_state: NULL
trx_tables_in_use: 0
trx_tables_locked: 0
trx_lock_structs: 3
trx_lock_memory_bytes: 360
trx_rows_locked: 3
trx_rows_modified: 1
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLEREAD
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
trx_is_read_only: 0
trx_autocommit_non_locking: 0
2rowsinset (0.03sec)

有些时候，我们主观上认为的一个 INSERT ，在新写入数据，理论上除了表锁和别人没啥冲突，毕竟还没写，也没人能更新它。不过这些细节上，间隙锁，Next Key Lock 等等，还是会影响到具体的执行。如果你也遇到类似的情况，有权限的时候，可以通过上面 MySQL ‘information_schema’.INNODB_自带的三个表，发现锁的冲突信息。如果没有权限，可以先想办法拿到事务日志，再进一步分析。

事务日志，可以通过 SHOW ENGINE INNODB STATUS 拿到，给迷茫的分析加一点思路。

文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/304821.html<