Anlamakta yardıma ihtiyaç duyduğum çok karışık bir kilitlenme durumu buldum.
(2) sorgusu delete from myTable where id = NAME_CONST('p_id',10000) için kilit tutan:İşlem kilitleme işlemini başlatmaya çalıştığında kilitlenme sorunu zaten var
oluyor iki işlemler vardır. Bu tam anahtar değil bir aralık olmasına rağmen PRIMARY KEY tarafından bir kilit. Bu, lock_mode X locks rec but not gap diyorsa bana tam bir yazma kilidi gibi görünüyor.
(1), delete from myTable where id = NAME_CONST('p_id',10000) sorgusu için de aynı kilidi beklemektedir.
(2) aynı zamanda bu kilidi almayı deniyor ve MySQL bir kilitlenme tespit ediyor.
Neyi anlayamadığım, (2) kilidin zaten tutulduğu kadar kilidi alması gerektiğidir ve her durumda bir yazma kilidi (lock_mode X).
Aynı sorgu için olduğu gibi görünüyor. İşte
tablo tanımıcreate myTable (
id int unsigned not null,
value1 char(8) not null,
value2 int unsigned,
primary key (id, value1)
);
ve burada aynı kilit değil SHOW ENGINE INNODB STATUS\G
------------------------
LATEST DETECTED DEADLOCK
------------------------
130313 14:46:28
*** (1) TRANSACTION:
TRANSACTION 75ACB8A3, ACTIVE 0 sec, process no 6110, OS thread id 139973945382656 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 5154970, query id 5201313618 192.168.0.2 user updating
delete from myTable where id = NAME_CONST('p_id',10000)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 22371 page no 1598 n bits 104 index `PRIMARY` of table `db`.`myTable` trx id 75ACB8A3 lock_mode X waiting
Record lock, heap no 32 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 0005af3a; asc :;;
1: len 8; hex 2020202020202020; asc ;;
2: len 6; hex 000075acb890; asc u ;;
3: len 7; hex ea0000020d011e; asc ;;
4: len 4; hex 00000065; asc e;;
*** (2) TRANSACTION:
TRANSACTION 75ACB890, ACTIVE 0 sec, process no 6110, OS thread id 139973957895936 starting index read
mysql tables in use 1, locked 1
7 lock struct(s), hea
p size 1248, 6 row lock(s), undo log entries 4
MySQL thread id 5155967, query id 5201313625 192.168.0.1 user updating
delete from myTable where id = NAME_CONST('p_id',10000)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 22371 page no 1598 n bits 104 index `PRIMARY` of table `db`.`myTable` trx id 75ACB890 lock_mode X locks rec but not gap
Record lock, heap no 32 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 0005af3a; asc :;;
1: len 8; hex 2020202020202020; asc ;;
2: len 6; hex 000075acb890; asc u ;;
3: len 7; hex ea0000020d011e; asc ;;
4: len 4; hex 00000065; asc e;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 22371 page no 1598 n bits 104 index `PRIMARY` of table `db`.`myTable` trx id 75ACB890 lock_mode X waiting
Record lock, heap no 32 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 0005af3a; asc :;;
1: len 8; hex 2020202020202020; asc ;;
2: len 6; hex 000075acb890; asc u ;;
3: len 7; hex ea0000020d011e; asc ;;
4: len 4; hex 00000065; asc e;;
*** WE ROLL BACK TRANSACTION (1)
Hata oluşturmaya çalıştınız mı? Eğer "evet" senaryosunu gösterebilir miydin? – ravnur
Bu silme işlemini "start transaction" ile olabildiğince hızlı yapmaya çalıştım; ... silmek; rollback; 'bash gibi hızlı iki iş parçacığı iş parçacığı mysql besleyebilir ama bir kez bir çıkmaz aldın. Bunun nasıl olabileceğine dair oldukça clueless. –
Lütfen bu soruya göz atın (deadlock'u nasıl yakalayabileceğinizi açıklar): http://stackoverflow.com/questions/2143873/how-to-explain-the-deadlock-better. Ayrıca, http://dwachira.hubpages.com/hub/Process-Deadlock-Definition-Prevention-Detection-Recovery-ve-Avoidance adresinin de bulunduğu, çıkmazdan tespit ve kurtarma hakkında oldukça güzel bir makale var. Genel olarak, kilitlenme mimarlık ve tasarım meselesidir. Verileri güncelleyen süreçlerinizi gözden geçirmelisiniz. – ravnur