Birden çok iş parçacığı tarafından eklenmesi nedeniyle MySQL'de kilitlenme

Question

Birden çok toplu işte bir tablodaki bir kaydın INSERT çalışmasını sağlayan çok iş parçacıklı bir uygulamam var. Her iş parçacığı bir toplu işleniyor. Zaman zaman Deadlock hatası alıyorum, takip izler.

tablo ben bir kayıt eklemek çalışıyorum şu şekildedir:

RecordBase (Col1, Col2, Col3)

Col1 ve Col2 birlikte bir bileşik birincil anahtar oluşturur.

Daha önce bir index-record kilidi nedeniyle olabileceğini düşündüm ancak iz, birbirini engelleyen ifadelerin çoğaltılmış kayıtları olmadığını açıkça gösteriyor. Öyleyse neden kilitlenme yapıyor?

------------------------ LATEST DETECTED DEADLOCK ------------------------ 
2015-09-09 17:13:22 2b70324de700 

*** (1) TRANSACTION: 
TRANSACTION 1787379600, ACTIVE 7 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 486 lock struct(s), heap size 63016, 13085 row lock(s), undo log entries 8713 MySQL thread id 537443, OS thread handle 0x2b703286c700, query id 578560605 127.0.0.1 192.168.1.195 demoreleaseroot update 
INSERT INTO Record_Base VALUES 
('da5fd95c-4d8e-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('da5fcf08-4d8e-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('da5fc4eb-4d8e-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('da5fbabe-4d8e-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('da5fb087-4d8e-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('da5fa616-4d8e-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('da5f99bf-4d8e-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('da5f8f0f-4d8e-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('da5f5e2e-4d8e-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('da5f52e3-4d8e-11e5-9761-22000bd9028a','101e7d 

*** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 26232190 page no 5961 n bits 160 index `PRIMARY` of table `provalant101_mxradon`.`Record_Base` trx id 1787379600 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 29 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 0: len 30; hex 65376566306364332d353039352d313165352d393736312d323230303062; asc e7ef0cd3-5095-11e5-9761-22000b; (total 36 bytes); 1: len 30; hex 31303165376463642d346338312d313165352d396361302d323230303062; asc 101e7dcd-4c81-11e5-9ca0-22000b; (total 36 bytes); 2: len 6; hex 00006a893f90; asc j ? ;; 3: len 7; hex b40001a7c3290f; asc  ) ;; 4: len 4; hex 80000000; asc  ;; *** 

(2) TRANSACTION: TRANSACTION 1787379848, ACTIVE 1 sec inserting mysql tables in use 1, locked 1 1030 lock struct(s), heap size 112168, 5801 row lock(s), undo log entries 2639 MySQL thread id 537467, OS thread handle 0x2b70324de700, query id 578563042 127.0.0.1 192.168.1.195 demoreleaseroot update INSERT INTO Record_Base VALUES 
('4849f98e-5094-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('4849ebe5-5094-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('4849c44c-5094-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('4849add7-5094-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('4849a0ef-5094-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('48499430-5094-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('48498752-5094-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('48496d2d-5094-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('4848731e-5094-11e5-9761-22000bd9028a','101e7dcd-4c81-11e5-9ca0-22000bd8028c','0'), 
('4846784e-5094-11e5-9761-22000bd9028a','101e7d 

*** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 26232190 page no 5961 n bits 152 index `PRIMARY` of table `provalant101_mxradon`.`Record_Base` trx id 1787379848 lock_mode X locks gap before rec Record lock, heap no 29 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 0: len 30; hex 65376566306364332d353039352d313165352d393736312d323230303062; asc e7ef0cd3-5095-11e5-9761-22000b; (total 36 bytes); 1: len 30; hex 31303165376463642d346338312d313165352d396361302d323230303062; asc 101e7dcd-4c81-11e5-9ca0-22000b; (total 36 bytes); 2: len 6; hex 00006a893f90; asc j ? ;; 3: len 7; hex b40001a7c3290f; asc  ) ;; 4: len 4; hex 80000000; asc  ;; 

*** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 26232190 page no 14639 n bits 192 index `PRIMARY` of table `provalant101_mxradon`.`Record_Base` trx id 1787379848 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 121 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 0: len 30; hex 38393531613333352d353039342d313165352d393736312d323230303062; asc 8951a335-5094-11e5-9761-22000b; (total 36 bytes); 1: len 30; hex 31303165376463642d346338312d313165352d396361302d323230303062; asc 101e7dcd-4c81-11e5-9ca0-22000b; (total 36 bytes); 2: len 6; hex 00006a893f90; asc j ? ;; 3: len 7; hex b40001a7c71c1c; asc  ;; 4: len 4; hex 80000000; asc  ;; 

*** WE ROLL BACK TRANSACTION (2) 

Answer 1

Bu tür kilitlenmeler Gap Kilitler olarak bilinir. Bu post'u oldukça yararlı buldum.

Ayrıca, nedeniyle mysql mekanizmalarının Geçmişten benim uygulamada sürü oldu Mysql Manual

Answer 2

Çıkmazda kilitleme boşluğu hakkında daha fazla bilgi bulabilirsiniz. İki yolla çözdüm. İlk olarak, aynı iş parçacığı aynı iş parçacığını etkileyen toplu işlerini sıraya koyup sıralı olarak çalıştırıyorum, ikincisi, kilitlenme hatasını yakalamak için sorgu yürütmeleri etrafında bir try-catch bloğu koydum ve denemeler arasında bir uyku fonksiyonu da dahil olmak üzere 5+ kez aynı sorgu yürütmeyi deneyelim .

Answer 3

Bu aynı sorunu bana anlattı, @Aashish'in cevabı bana açıkladı, bu yüzden neden bunun benim için çalıştığını anlamak istiyorsanız cevabını okumalısınız.

Ben senaryo:

Ben sütunları Tarih ve idSomething üzerinde benzersiz bir dizin Ben 12 parçacığı bir havuz takmadan

vardı (sipariş önemlidir, Tarih 1 ve idSomething ikinci oldu) Her idSomething için aynı tarih aralığı (3 gün) (Yaklaşık 1500 farklı idSomethings).

düzeltme: Sütun idSomething (1) ve Tarih (2) olmak EŞSİZ endeksi değiştirme

. Daha sonra, "Somethings" i düzenli bir şekilde işlemek yerine, siparişe bir karışıklık ekledim, bu yüzden idSomething I ve I + 1'in aynı anda bir araya getirilmesi daha az olasıdır. Bu şekilde Gap Kilitler birbiriyle çakışmadı ve deadlock'lar başarısız oldu.