mysql行锁等待异常

根据我之前接触到的此类问题，大致可以分为以下几种原因：

1. 程序中非数据库交互 *** 作导致事务挂起

将接口调用或者文件 *** 作等这一类非数据库交互 *** 作嵌入在 SQL 事务代码之中，那么整个事务很有可能因此挂起（接口不通等待超时或是上传下载大附件）。

2. 事务中包含性能较差的查询 SQL

事务中存在慢查询，导致同一个事务中的其他 DML 无法及时释放占用的行锁，引起行锁等待。

3. 单个事务中包含大量 SQL

通常是由于在事务代码中加入 for 循环导致，虽然单个 SQL 运行很快，但是 SQL 数量一大，事务就会很慢。

4. 级联更新 SQL 执行时间较久

这类 SQL 容易让人产生错觉，例如：update A set ... where ...in (select B) 这类级联更新，不仅会占用 A 表上的行锁，也会占用 B 表上的行锁，当 SQL 执行较久时，很容易引起 B 表上的行锁等待。

5. 磁盘问题导致的事务挂起

极少出现的情形，比如存储突然离线，SQL 执行会卡在内核调用磁盘的步骤上，一直等待，事务无法提交。

综上可以看出，如果事务长时间未提交，且事务中包含了 DML *** 作，那么就有可能产生行锁等待，引起报错。

这是我见的一个文档，虽然我看不懂，你看看有没有帮助

MySQL死锁问题的相关知识是本文我们主要要介绍的内容，接下来我们就来一一介绍这部分内容，希望能够对您有所帮助。

1、MySQL常用存储引擎的锁机制

MyISAM和MEMORY采用表级锁(table-level locking)

BDB采用页面锁(page-level locking)或表级锁，默认为页面锁

InnoDB支持行级锁(row-level locking)和表级锁，默认为行级锁

2、各种锁特点

表级锁：开销小，加锁快不会出现死锁锁定粒度大，发生锁冲突的概率最高，并发度最低

行级锁：开销大，加锁慢会出现死锁锁定粒度最小，发生锁冲突的概率最低，并发度也最高

页面锁：开销和加锁时间界于表锁和行锁之间会出现死锁锁定粒度界于表锁和行锁之间，并发度一般

3、各种锁的适用场景

表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用

行级锁则更适合于有大量按索引条件并发更新数据，同时又有并发查询的应用，如一些在线事务处理系统

4、死锁

是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。

表级锁不会产生死锁。所以解决死锁主要还是针对于最常用的InnoDB。

5、死锁举例分析

在MySQL中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql语句 *** 作了主键索引，MySQL就会锁定这条主键索引如果一条语句 *** 作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。

在UPDATE、DELETE *** 作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-key locking。

例如，一个表db。tab_test，结构如下：

id：主键

state：状态

time：时间

索引：idx_1(state，time)

出现死锁日志如下：

?***(1) TRANSACTION:

?TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OSthread id 278546 starting index read

?mysql tables in use 1, locked 1

?LOCK WAIT 3 lock struct(s), heap size 320

?MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update

?update tab_test set state=1064,time=now() where state=1061 and time <date_sub(now(), INTERVAL 30 minute) (任务1的sql语句)

?***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任务1等待的索引记录)

?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting

?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11compact formatinfo bits 0

?0: len 8hex 800000000097629casc b 1: len 6hex 00002866eaeeasc (f 2: len 7hex 00000d40040110asc @ 3: len 8hex 80000000000050b2asc P 4: len 8hex 800000000000502aasc P*5: len 8hex 8000000000005426asc T&6: len 8hex 800012412c66d29casc A,f 7: len 23hex 75706c6f6164666972652e636f6d2f6 8616e642e706870asc xxx.com/8: len 8hex 800000000000042basc +9: len 4hex 474bfa2basc GK +10: len 8hex 8000000000004e24asc N$

?*** (2) TRANSACTION:

?TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499

?mysql tables in use 1, locked 1

?3 lock struct(s), heap size 320, undo log entries 1

?MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) (任务2的sql语句)

?*** (2) HOLDS THE LOCK(S): (任务2已获得的锁)

?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap

?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11compact formatinfo bits 0

?0: len 8hex 800000000097629casc b 1: len 6hex 00002866eaeeasc (f 2: len 7hex 00000d40040110asc @ 3: len 8hex 80000000000050b2asc P 4: len 8hex 800000000000502aasc P*5: len 8hex 8000000000005426asc T&6: len 8hex 800012412c66d29casc A,f 7: len 23hex 75706c6f6164666972652e636f6d2f6 8616e642e706870asc uploadfire.com/hand.php8: len 8hex 800000000000042basc +9: len 4hex 474bfa2basc GK +10: len 8hex 8000000000004e24asc N$

?*** (2) WAITING FOR THIS LOCK TO BE GRANTED: (任务2等待的锁)

?RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting

?Record lock, heap no 395 PHYSICAL RECORD: n_fields 3compact formatinfo bits 0

?0: len 8hex 8000000000000425asc %1: len 8hex 800012412c66d29casc A,f 2: len 8hex 800000000097629casc b

?*** WE ROLL BACK TRANSACTION (1)

?(回滚了任务1，以解除死锁)

原因分析：

当“update tab_test set state=1064,time=now() where state=1061 and time <date_sub(now(), INTERVAL 30 minute)”执行时，MySQL会使用idx_1索引，因此首先锁定相关的索引记录，因为idx_1是非主键索引，为执行该语句，MySQL还会锁定主键索引。

假设“update tab_test set state=1067,time=now () where id in (9921180)”几乎同时执行时，本语句首先锁定主键索引，由于需要更新state的值，所以还需要锁定idx_1的某些索引记录。

这样第一条语句锁定了idx_1的记录，等待主键索引，而第二条语句则锁定了主键索引记录，而等待idx_1的记录，这样死锁就产生了。

6、解决办法

拆分第一条sql，先查出符合条件的主键值，再按照主键更新记录：

?select id from tab_test where state=1061 and time <date_sub(now(), INTERVAL 30 minute)

?update tab_test state=1064,time=now() where id in(......)

行级锁 是说最小粒度的锁是行级锁。

当需要更新同一个页面中的数据时，是会升级到页面锁的。

当对整个表进行更新时，会使用表级锁；

如果此时使用一个一个行级锁，不光浪费资源，也会影响效率。

---