2015-02-23 1 views
0

Я прошел через журналы MySQL и нашел причину тупиковойMySQL Тупик - доступ к различным значению первичного ключа также создание тупиковой ситуации

первой нить пытается выполнить ниже запроса. Что ждет нить 2.

UPDATE M_SAMP SET FLAG=0 WHERE M_ID IN (SELECT M_ID FROM MM_RVW_SAMP WHERE TARGET_M_ID IN(19)) 

В результате внутреннего запроса (SELECT M_ID FROM MM_RVW_SAMP WHERE TARGET_M_ID IN(19)) является M_ID = 3562.

2-я строка выполняется ниже запроса.

DELETE FROM M_SAMP WHERE M_ID=3455 

Существует no foreign key отношение, определенное в M_SAMP и MM_RVW_SAMP таблиц. И M_ID является первичным ключом таблицы M_SAMP. И двигатель InnoDB. И этот вопрос повторяется.

Может ли кто-нибудь помочь мне, как шлюзы предоставляются, из-за чего происходит тупик?

Журналы

------------------------ 
LATEST DETECTED DEADLOCK 
------------------------ 
2015-02-23 10:52:28 de8 
*** (1) TRANSACTION: 
TRANSACTION 13275344, ACTIVE 0 sec fetching rows 
mysql tables in use 2, locked 2 
LOCK WAIT 25 lock struct(s), heap size 2408, 1394 row lock(s), undo log entries 1 
MySQL thread id 1455, OS thread handle 0x11ac, query id 39660 xyz 192.168.1.108 userName Sending data 
UPDATE M_SAMP SET FLAG=0 WHERE M_ID IN (SELECT M_ID FROM MM_RVW_SAMP WHERE TARGET_M_ID IN(19)) 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 61569 page no 65 n bits 176 index `PRIMARY` of table `dbName`.`m_samp` trx id 13275344 lock_mode X waiting 
Record lock, heap no 3 PHYSICAL RECORD: n_fields 29; compact format; info bits 0 

*** (2) TRANSACTION: 
TRANSACTION 13275335, ACTIVE 0 sec starting index read 
mysql tables in use 1, locked 1 
254 lock struct(s), heap size 27512, 21595 row lock(s), undo log entries 7 
MySQL thread id 1458, OS thread handle 0xde8, query id 39664 xyz 192.168.1.108 userName updating 
DELETE FROM M_SAMP WHERE M_ID=3455 
*** (2) HOLDS THE LOCK(S): 
RECORD LOCKS space id 61569 page no 65 n bits 176 index `PRIMARY` of table `dbName`.`m_samp` trx id 13275335 lock mode S locks rec but not gap 
Record lock, heap no 3 PHYSICAL RECORD: n_fields 29; compact format; info bits 0 

Спасибо.

+0

Проблема решена путем выполнения внутреннего запроса на запрос обновления и передачи возвращаемого значения для обновления запроса. Но все же я хочу знать, какой тип блокировки происходит, когда я непосредственно выполняю запрос на обновление с помощью внутреннего запроса? –

ответ

0

Ответ на мой вопрос дается here (on dba.stackexchange) от @jynus.

Теперь я использую ниже запрос на обновление.

UPDATE M_SAMP M 
JOIN MM_RVW_SAMP MM 
ON M.M_ID = MM. M_ID 
SET M.FLAG = 1 
WHERE MM.TARGET_M_ID = 19;