MySQL死锁简单案例演示【存在疑问】
请各位读者对本篇文章采取疑问的态度。
1.环境
- mysql 5.7
- windows
2.示例1
mysql> CREATE TABLE t (i INT) ENGINE = InnoDB;
Query OK, 0 rows affected (0.26 sec)
- Client A起事务，以share 锁模式读取数据
mysql> start transaction;
Query OK, 0 rows affected (0.03 sec)
mysql> SELECT * FROM t WHERE i = 1 lock in SHARE mode;
+------+
| i |
+------+
| 1 |
+------+
1 row in set (0.00 sec)
- Client B另起事务，删除表t中的数据
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> delete from t;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
上面的这个超时错将会在命令执行一段时间之后，才出现。其超时时间默认设置为50s：
mysql> show variables like 'innodb_lock_wait_timeout';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 50 |
+--------------------------+-------+
1 row in set, 1 warning (0.03 sec)
在这个出错命令尚未出现之前，在Client A中继续执行如下命令：
mysql> DELETE FROM t WHERE i = 1;
Query OK, 1 row affected (0.00 sec)
结果在Client B中出现的结果如下：
mysql> DELETE FROM t WHERE i = 1;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
3.示例2【外键约束至死锁】
- 建表语句
CREATE TABLE `parent` (
`id` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
CREATE TABLE `child` (
`id` int(11) DEFAULT NULL,
KEY `id_for` (`id`),
CONSTRAINT `id_for` FOREIGN KEY (`id`) REFERENCES `parent` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
- 执行SQL
在session A执行如下命令：
mysql> begin;
Query OK, 0 rows affected (0.03 sec)
mysql> delete from parent where id = 3;
Query OK, 1 row affected (0.01 sec)
在session B执行如下命令：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into child select 3;
发现Session B的回话一直呈阻塞态。
查看information_schema.innodb_locks表数据，如下：
mysql> select * from information_schema.innodb_locks\G
*************************** 1. row ***************************
lock_id: 21305:145:3:4
lock_trx_id: 21305
lock_mode: S
lock_type: RECORD
lock_table: `insidemysql`.`parent`
lock_index: PRIMARY
lock_space: 145
lock_page: 3
lock_rec: 4
lock_data: 3
*************************** 2. row ***************************
lock_id: 21303:145:3:4
lock_trx_id: 21303
lock_mode: X
lock_type: RECORD
lock_table: `insidemysql`.`parent`
lock_index: PRIMARY
lock_space: 145
lock_page: 3
lock_rec: 4
lock_data: 3
2 rows in set, 1 warning (0.01 sec)
发现出现死锁。
死锁过程很简单：Session A首先发起一个事务（以begin起），接着欲删除parent表中id=3的行记录。这个操作会发起锁操作，申请一个x锁【如上述SQL所示，lock_trx_id为21303，其lock_mode为x型】。然后另外的一个回话Session B发起一个事务（begin起），欲插入一条id=3的记录【如上述SQL所示，lock_trx_id为21305，其lock_mode为s型】。但是因为parent表中的id是child表中的id的外键，所以导致阻塞的产生。注意它们的lock_id 以及lock_data均相同，表明锁住的行记录相同。
4. 参考文章
-
1.https://dev.mysql.com/doc/refman/5.7/en/innodb-deadlock-example.html
我对本文是有疑问的，因为在Client A中是可以直接删除数据的，而不是Client A陷入了死锁。参考文献对于这个问题可能产生死锁的解释是：- Client A 获得一个s锁（并一直持有【用事务保持状态】）
- Client B请求获得一个x锁（删除某行数据）
- Client A接着请求一个x锁（也想删除该行数据）
- 于是Client A，B均陷入死锁
-
2.《Mysql技术内幕：InnoDB存储引擎》
