我们有一个表，用于存储公司（公司将有多个用户）的登录信息，并在该公司的任何用户登录时删除公司的所有记录（该公司的所有记录）。 对于上述情况，我们将收到死锁，无法从应用程序端进行更改。 没有间隙锁定发生，并且两个删除都使用正确的索引。在进行索引扫描时，应按顺序读取数据。如果是顺序顺序，则第二条语句应等待获取锁，但这会导致死锁。 MariaDB版本：10.2.14 隔离：已提交
Below the table DDL
CREATE TABLE `TableA` (
`TableAKY` INT(11) NOT NULL AUTO_INCREMENT,
`PERSONKY` INT(11) NOT NULL,
`ID` INT(11) NULL DEFAULT NULL,
`PackageName` VARCHAR(150) NOT NULL COLLATE 'utf8_bin',
`LOCKEDKY` BIGINT(20) NULL DEFAULT NULL,
`LASTACTIVITYDTTM` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
`UPDATEDTTM` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
`UPDATEUSER` VARCHAR(32) NOT NULL DEFAULT 'SYSTEM' COLLATE 'utf8_bin',
`VERSIONSTAMP` SMALLINT(6) NOT NULL DEFAULT '1',
`USERKY` INT(11) NULL DEFAULT '0',
PRIMARY KEY (`TableAKY`),
INDEX `TableA_GI1` (`LASTACTIVITYDTTM`),
INDEX `TableA_GI2` (`PERSONKY`),
INDEX `TableA_GI4` (`LOCKEDKY`),
INDEX `TableA_GI3` (`ID`, `LASTACTIVITYDTTM`),
CONSTRAINT `TableA_FK1` FOREIGN KEY (`PERSONKY`) REFERENCES `corperson` (`PERSONKY`)
)
COLLATE='utf8_bin'
ENGINE=InnoDB;
显示创建表在下面
CREATE TABLE `TableA` (
`TableAKY` INT(11) NOT NULL AUTO_INCREMENT,
`PERSONKY` INT(11) NOT NULL,
`ID` INT(11) NULL DEFAULT NULL,
`PackageName` VARCHAR(150) NOT NULL COLLATE 'utf8_bin',
`LOCKEDKY` BIGINT(20) NULL DEFAULT NULL,
`LASTACTIVITYDTTM` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
`UPDATEDTTM` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
`UPDATEUSER` VARCHAR(32) NOT NULL DEFAULT 'SYSTEM' COLLATE 'utf8_bin',
`VERSIONSTAMP` SMALLINT(6) NOT NULL DEFAULT '1',
`USERKY` INT(11) NULL DEFAULT '0',
PRIMARY KEY (`TableAKY`),
INDEX `TableA_GI1` (`LASTACTIVITYDTTM`),
INDEX `TableA_GI2` (`PERSONKY`),
INDEX `TableA_GI4` (`LOCKEDKY`),
INDEX `TableA_GI3` (`ID`, `LASTACTIVITYDTTM`),
CONSTRAINT `TableA_FK1` FOREIGN KEY (`PERSONKY`) REFERENCES `corperson` (`PERSONKY`),
CONSTRAINT `TableA_CK9` CHECK (`VERSIONSTAMP` >= 0)
) ENGINE=InnoDB AUTO_INCREMENT=495189 DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=DYNAMIC;
方案1 -----------从同一张表中删除不同的记录，但是不同的会话会导致死锁
2019-09-05 11:02:06 140065601476352 [Note] InnoDB: Transactions deadlock detected, dumping detailed information.
2019-09-05 11:02:06 140065601476352 [Note] InnoDB:
*** (1) TRANSACTION:
TRANSACTION 3665046721, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 1
MySQL thread id 7139751, OS thread handle 140065636890368, query id 16445911731 <IP of Application 1> appid Updating
delete from TableA where current_timestamp>=lastActivityDtTm and ID=3
2019-09-05 11:02:06 140065601476352 [Note] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 26908 page no 4 n bits 72 index TableA_GI1 of table `DatabaseA`.`TableA` trx id 3665046721 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 4; hex 5d70818e; asc ]p ;;
1: len 4; hex 80125384; asc S ;;
2019-09-05 11:02:06 140065601476352 [Note] InnoDB: *** (2) TRANSACTION:
TRANSACTION 3665046667, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 7126671, OS thread handle 140065601476352, query id 16445907427 <IP of Application 2> appid Updating
delete from TableA where current_timestamp>=lastActivityDtTm and ID=229753
2019-09-05 11:02:06 140065601476352 [Note] InnoDB: *** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 26908 page no 4 n bits 72 index TableA_GI1 of table `DatabaseA`.`TableA` trx id 3665046667 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 4; hex 5d70818e; asc ]p ;;
1: len 4; hex 80125384; asc S ;;
2019-09-05 11:02:06 140065601476352 [Note] InnoDB: (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 26908 page no 4 n bits 72 index TableA_GI1 of table `DatabaseA`.`TableA` trx id 3665046667 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 4; hex 5d7081a9; asc ]p ;;
1: len 4; hex 80125385; asc S ;;
2019-09-05 11:02:06 140065601476352 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (2)
方案2 -----------从同一表中删除相同的记录，但是不同的会话会导致死锁
2019-09-06 13:00:11 140064167008000 [Note] InnoDB: Transactions deadlock detected, dumping detailed information.
2019-09-06 13:00:11 140064167008000 [Note] InnoDB:
*** (1) TRANSACTION:
TRANSACTION 3671781064, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 1
MySQL thread id 7298913, OS thread handle 140064152139520, query id 16923847059 <IP of Application 2> appid Updating
delete from TableA where current_timestamp>=lastActivityDtTm and ID=1155003
2019-09-06 13:00:11 140064167008000 [Note] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 26908 page no 6 n bits 96 index TableA_GI3 of table `sparkdb`.`TableA` trx id 3671781064 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 4; hex 80119fbb; asc ;;
1: len 4; hex 5d71eed4; asc ]q ;;
2: len 4; hex 8012590a; asc Y ;;
2019-09-06 13:00:11 140064167008000 [Note] InnoDB: *** (2) TRANSACTION:
TRANSACTION 3671780157, ACTIVE 15 sec starting index read
mysql tables in use 1, locked 1
549 lock struct(s), heap size 73936, 66 row lock(s), undo log entries 48
MySQL thread id 7277612, OS thread handle 140064167008000, query id 16923851347 <IP of Application 2> appid Updating
delete from TableA where current_timestamp>=lastActivityDtTm and ID=1155003
2019-09-06 13:00:11 140064167008000 [Note] InnoDB: *** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 26908 page no 6 n bits 96 index TableA_GI3 of table `sparkdb`.`TableA` trx id 3671780157 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 4; hex 80119fbb; asc ;;
1: len 4; hex 5d71eed4; asc ]q ;;
2: len 4; hex 8012590a; asc Y ;;
2019-09-06 13:00:11 140064167008000 [Note] InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 26908 page no 6 n bits 96 index TableA_GI3 of table `sparkdb`.`TableA` trx id 3671780157 lock_mode X locks rec but not gap waiting
Record lock, heap no 21 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 4; hex 80119fbb; asc ;;
1: len 4; hex 5d71ed15; asc ]q ;;
2: len 4; hex 801258ff; asc X ;;
2019-09-06 13:00:11 140064167008000 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (1)
Am i missing something to consider resolving this deadlock? , please help. Thanks in advance