Why is it deadlocked(using innodb) ？ - mysql

Question

Note:
engine = innodb (mysql)
tx_isolation = Read-Committed
create table sql:
CREATE TABLE `table_test` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`to_uid` varchar(16) NOT NULL,
`time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP,
`to_sid` varchar(100) DEFAULT NULL,
`session_id` varchar(16) DEFAULT NULL ,
PRIMARY KEY (`id`),
UNIQUE KEY `to_uid_to_sid` (`to_uid`,`to_sid`) ,
KEY `idx_uid_time` (`to_uid`,`time`) ,
KEY `idx_uId_session` (`to_uid`,`session_id`,`time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
When execute delete statements concurrently ,the unique index to_uid_to_sid and index to_uid_time are both used, the sql is:
DELETE FROM table_test WHERE to_uid='111222' and to_sid in ('xxx','yyyy')
But find deadLock!
DeadLock log is:
------------------------
LATEST DETECTED DEADLOCK
------------------------
2021-08-02 17:54:26 2b075b19b700
*** (1) TRANSACTION:
TRANSACTION 41417931055, ACTIVE 0.000 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 6 lock struct(s), heap size 1184, 6 row lock(s), undo log entries 2
LOCK BLOCKING MySQL thread id: 13894454 block 13894734
MySQL thread id 13894734, OS thread handle 0x2b0b48bc0700, query id 86568609815 172.16.10.213 m_user updating
DELETE FROM table_test WHERE to_uid='111222' and to_sid in ('411-91fb-418f-ae2d-f0a48bb767aa', 'ffa-a04d-4a80-b969-43e068c366ed', '655-f2cc-4198-bf65-c918995877c3')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1334 page no 647280 n bits 96 index `PRIMARY` of table `chat`.`table_test` trx id 41417931055 lock_mode X locks rec but not gap waiting
Record lock, heap no 5 PHYSICAL RECORD: n_fields 10; compact format; info bits 32
0: len 8; hex 8000000007df89ec; asc ;;
1: len 6; hex 0009a4b37930; asc y0;;
2: len 7; hex 5800003a4623ae; asc X :F# ;;
3: len 9; hex 313439383233353735; asc 149823575;;
4: len 30; hex 7b2276223a312c22736964223a2238303436653739652d623165302d3461; (total 338 bytes);
5: len 4; hex 80000000; asc ;;
6: len 4; hex 6107c06c; asc a l;;
*** (2) TRANSACTION:
TRANSACTION 41417931056, ACTIVE 0.000 sec updating or deleting
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1184, 3 row lock(s), undo log entries 1
MySQL thread id 13894454, OS thread handle 0x2b075b19b700, query id 86568609816 172.16.10.213 dml_user updating
DELETE FROM table_test WHERE to_uid='111222' and to_sid in ('79e-b1e0-4afa-86c9-627cf1476209')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS sp ace id 1334 page no 647280 n bits 96 index `PRIMARY` of table `chat`.`table_test` trx id 41417931056 lock_mode X locks rec but not gap
Record lock, heap no 5 PHYSICAL RECORD: n_fields 10; compact format; info bits 32
0: len 8; hex 8000000007df89ec; asc ;;
1: len 6; hex 0009a4b37930; asc y0;;
2: len 7; hex 5800003a4623ae; asc X :F# ;;
3: len 9; hex 313439383233353735; asc 149823575;;
4: len 30; hex 7b2276223a312c22736964223a223830343665373965223165302d3461; asc ; (total 338 bytes);
5: len 4; hex 80000000; asc ;;
6: len 4; hex 6107c06c; asc a l;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1334 page no 474871 n bits 440 index `idx_uid_time` of table `chat`.`table_test` trx id 41417931056 lock_mode X locks rec but not gap waiting
Record lock, heap no 364 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 9; hex 313439383233353735; asc 149823575;;
1: len 4; hex 6107c06c; asc a l;;
2: len 8; hex 8000000007df89ec; asc ;;
*** WE ROLL BACK TRANSACTION (2)
------------
TRANSACTIONS
------------

Answer 1

Not all deadlocks are preventable. Your client should check for such and replay the transaction in the case of a deadlock or a lock_wait_timeout.
What was the logic behind using READ_COMMITTED?
Was there anything other than the DELETE in each of the competing transactions?
I cannot explain this particular deadlock.
Some possible improvements...
Some of the items below are aimed at performance. One way to partially avoid deadlocks is to speed up the queries, thereby getting them finished faster, thereby more often avoiding conflicts.
You have two UNIQUE keys on that table. This leads to extra work and extra chances for deadlocks. Is id used in any other way (such as an FK from another table)? If not, get rid of it.
I would consider replacing all 4 indexes by this one:
PRIMARY KEY(`to_uid`,`to_sid`)
I don't think the other two secondary keys would buy much now that to_uid is the start of the PK, so I tossed them. What is the cardinality of to_uid?
'79e-b1e0-4afa-86c9-627cf1476209' looks like a UUID. If they are all that form, then VARCHAR(100) is overkill; CHAR(36) suffices. (However, that won't improve anything.) Converting to BINARY(16) would provide a significant shrinkage -- which might help performance some.
You have to_uid varchar(16), but the example looks like a number. If that is always numeric, then a numeric datatype would be slightly better (and smaller).