Как решить MySQL тупик

Question

в MySQL возникает следующая тупик.

*** (1) TRANSACTION:
TRANSACTION 1367965, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 16 lock struct(s), heap size 992, 8 row lock(s), undo log entries 4
MySQL thread id 100, OS thread handle 0x1fbc, query id 825084 localhost ::1 root updating
UPDATE `products` SET `quantity`=1333 WHERE (`id` = 3355)

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2503 page no 212 n bits 96 index `PRIMARY` of table `emerx2`.`products` trx id 1367965 lock_mode X locks rec but not gap waiting
Record lock, heap no 22 PHYSICAL RECORD: n_fields 66; compact format; info bits 0


*** (2) TRANSACTION:
TRANSACTION 1367967, ACTIVE 1 sec fetching rows
mysql tables in use 1, locked 1
2231 lock struct(s), heap size 125816, 43033 row lock(s)
MySQL thread id 87, OS thread handle 0x3a98, query id 825080 localhost 127.0.0.1 root updating
UPDATE products SET updated = NOW(), active = 1, supplier_id = '109', delivery_date = '2019-02-21 16:00:43', quantity = '1' WHERE supplier_id = '109' AND domain_id = 16

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 2503 page no 212 n bits 96 index `PRIMARY` of table `emerx2`.`products` trx id 1367967 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0

Есть ли какое-нибудь возможное решение?Я понятия не имею, что делать, потому что следующие обновления не имеют ничего общего только с таблицей.

Answer 1

Просто есть INDEX(supplier_id, domain_id).Не сначала получите идентификатор;пусть MySQL позаботится об этом.И это избавит от необходимости сканировать таблицу - что может привести к тупикам или задержкам.

Answer 2

Проблема заключалась в том, что в команде обновления я использовал 2 неиндексированных столбца.Итак, теперь я выбираю первичный ключ по этим двум столбцам, а затем обновляюсь первичным ключом, и он работает, и неожиданно он стал намного быстрее.