InnoDB: Why does transaction wait for IX lock when it already has a X lock? - innodb

Question

I'm getting a deadlock in my code. Txn 1 is waiting for a lock to be granted which is held currently by Txn 2. Txn 2 already has a X lock but still is requesting for a IX lock.
Both the transactions run an Insert query using ActiveRecord import.
The deadlock section in SHOW ENGINE INNODB STATUS gives me:
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 7431 page no 178 n bits 80 index PRIMARY of table `company_ebdb`.`user_metrics` trx id 51241147861 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 7431 page no 178 n bits 80 index PRIMARY of table `company_ebdb`.`user_metrics` trx id 51241147863 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 7431 page no 178 n bits 80 index PRIMARY of table `company_ebdb`.`user_metrics` trx id 51241147863 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
My question is why does Txn 2 need an IX lock if it already holds an X lock?
Update 1:
Here is the complete LATEST DETECTED DEADLOCK section:
------------------------
LATEST DETECTED DEADLOCK
------------------------
2022-09-02 16:11:22 0x149b2c2ef700
*** (1) TRANSACTION:
TRANSACTION 51241147861, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 8 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 1
MySQL thread id 8423321, OS thread handle 22689954051840, query id 19045173171 172.31.15.180 mitdb4dm1n update
INSERT INTO `user_metrics` (`id`,`current`,`total`,`my_type`,`owner_id`,`owner_type`,`created_at`,`updated_at`) VALUES (NULL,175,175,0,108840,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,100,151,0,108841,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,169,169,0,112780,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,202,217,0,112781,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,26,62,0,112782,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,169,169,0,112794,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,177,217,0,112795,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,28,62,0,112796,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,140,140,0,114162,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,64,64,0,114163,'OwnerName','2022-09-0
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 7431 page no 178 n bits 80 index PRIMARY of table `company_ebdb`.`user_metrics` trx id 51241147861 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** (2) TRANSACTION:
TRANSACTION 51241147863, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
7 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 1
MySQL thread id 8424694, OS thread handle 22656693761792, query id 19045173179 172.31.4.27 mitdb4dm1n update
INSERT INTO `user_metrics` (`id`,`current`,`total`,`my_type`,`owner_id`,`owner_type`,`created_at`,`updated_at`) VALUES (NULL,1,89,0,137623,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,0,3,0,137624,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,178,182,0,137635,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,77,129,0,137645,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,5,14,0,137646,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,0,87,0,137656,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,0,11,0,137657,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,71,71,0,146601,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,71,71,0,146616,'OwnerName','2022-09-02 16:11:22','2022-09-02 16:11:22'),(NULL,39,64,0,146631,'OwnerName','2022-09-02 16:11:22','2022-0
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 7431 page no 178 n bits 80 index PRIMARY of table `company_ebdb`.`user_metrics` trx id 51241147863 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 7431 page no 178 n bits 80 index PRIMARY of table `company_ebdb`.`user_metrics` trx id 51241147863 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** WE ROLL BACK TRANSACTION (2)
Update 2:
Create table output for the table involved:
CREATE TABLE `user_metrics` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`current` decimal(10,0) DEFAULT NULL,
`total` decimal(10,0) DEFAULT NULL,
`my_type` int(11) DEFAULT NULL,
`owner_id` int(11) DEFAULT NULL,
`owner_type` varchar(255) DEFAULT NULL,
`created_at` datetime NOT NULL,
`updated_at` datetime NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `index_user_metrics_on_owner_type_and_owner_id_and_my_type` (`owner_type`,`owner_id`,`my_type`)
) ENGINE=InnoDB AUTO_INCREMENT=1167 DEFAULT CHARSET=utf8mb4

Answer 1

Plan A:
Live with it. But do catch the error and replay the INSERT.
Plan B:
Try this. (I have no confidence that it will help):
You have two Unique keys (the PK is one). Let's switch them around, to the following. (It assumes you can change all three columns to NOT NULL.)
PRIMARY KEY(`owner_type`,`owner_id`,`my_type`),
INDEX(id)
Rationale:
Two Unique keys leads to two things being locked, and more than twice the likelihood of a conflict.
Having the data clustered in the order that is beneficial to the query will speed up the query, hence making it more likely to finish before conflicting with another connection.
I doubt if either of these will be sufficient to prevent deadlocks. But they may decrease the frequency of deadlocks. Hence, plan doing Plan A, too.