Kesulitan menguraikan kebuntuan dalam log status innodb

Kami sedang mengakses MySQL dari konektor Microsoft ADO.NET.

Kadang-kadang kita melihat kebuntuan berikut dalam status innodb kita dan belum dapat mengidentifikasi penyebab masalah. Sepertinya transaksi (2) sedang menunggu dan memegang kunci yang sama?

------------------------
LATEST DETECTED DEADLOCK
------------------------
110606  5:35:09
*** (1) TRANSACTION:
TRANSACTION 0 45321452, ACTIVE 0 sec, OS thread id 3804 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 368, 1 row lock(s)
    MySQL thread id 84, query id 3265713 localhost 127.0.0.1 famdev Updating
    UPDATE people SET company_id = 1610, name = '<name>', password = '<hash>', temp_password = NULL, reset_password_hash = NULL, email = '<redacted>@yahoo.com', phone = NULL, mobile = '<phone>', iphone_device_id = 'android:<id>-<id>', iphone_device_time = '2011-06-06 05:35:09', last_checkin = '2011-06-06 05:24:42', location_lat = <lat>, location_long = -<lng>, gps_strength = 3296, picture_blob_id = 1190, authority = 1, active = 1, date_created = '2011-04-13 20:21:20', last_login = '2011-06-06 05:35:09', panic_mode = 0, battery_level = NULL, battery_state = NULL WHERE people_id = 3125
    *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
    RECORD LOCKS space id 0 page no 11144 n bits 152 index `PRIMARY` of table `family`.`people` trx id 0 45321452 lock_mode X locks rec but not gap waiting
    Record lock, heap no 12 PHYSICAL RECORD: n_fields 25; compact format; info bits 0
    0: len 8; hex 8000000000000c35; asc        5;; 1: len 6; hex 000002b38ce6; asc       ;; 2: len 7; hex 00000002801f89; asc        ;; 3: len 8; hex 800000000000064a; asc        J;; 4: len 4; hex <data>; asc <name>;; 5: len 30; hex <data>; asc <data>;...(truncated); 6: SQL NULL; 7: SQL NULL; 8: len 16; hex <data>; asc <redacted>@yahoo.com;; 9: SQL NULL; 10: len 10; hex <data>; asc <phone>;; 11: len 30; hex <data>; asc android:<id>;...(truncated); 12: len 8; hex <data>; asc    J]  Z;; 13: len 8; hex <data>; asc    J]  Z;; 14: len 8; hex a39410acaa9b4340; asc       C@;; 15: len 8; hex <data>; asc     m S ;; 16: len 2; hex 8ce0; asc   ;; 17: len 8; hex 80000000000004a6; asc         ;; 18: len 4; hex 80000001; asc     ;; 19: len 1; hex 81; asc  ;; 20: len 8; hex <data>; asc    JR   ;; 21: len 8; hex <data>; asc    J]   ;; 22: len 1; hex 80; asc  ;; 23: SQL NULL; 24: SQL NULL;

    *** (2) TRANSACTION:
    TRANSACTION 0 45321448, ACTIVE 0 sec, OS thread id 3176 starting index read, thread declared inside InnoDB 500
    mysql tables in use 1, locked 1
    5 lock struct(s), heap size 1216, 2 row lock(s), undo log entries 1
    MySQL thread id 85, query id 3265714 localhost 127.0.0.1 famdev Updating
    UPDATE people SET company_id = 1610, name = '<name>', password = '<hash>', temp_password = NULL, reset_password_hash = NULL, email = '<redacted>@yahoo.com', phone = NULL, mobile = '<phone>', iphone_device_id = 'android:<id>-<id>-<id>-<id>', iphone_device_time = '2011-06-06 05:24:42', last_checkin = '2011-06-06 05:35:07', location_lat = <lat>, location_long = -<lng>, gps_strength = 3296, picture_blob_id = 1190, authority = 1, active = 1, date_created = '2011-04-13 20:21:20', last_login = '2011-06-06 05:35:09', panic_mode = 0, battery_level = NULL, battery_state = NULL WHERE people_id = 3125
    *** (2) HOLDS THE LOCK(S):
        RECORD LOCKS space id 0 page no 11144 n bits 152 index `PRIMARY` of table `family`.`people` trx id 0 45321448 lock mode S locks rec but not gap
        Record lock, heap no 12 PHYSICAL RECORD: n_fields 25; compact format; info bits 0
        0: len 8; hex 8000000000000c35; asc        5;; 1: len 6; hex 000002b38ce6; asc       ;; 2: len 7; hex 00000002801f89; asc        ;; 3: len 8; hex 800000000000064a; asc        J;; 4: len 4; hex <data>; asc <name>;; 5: len 30; hex <data>; asc <data>;...(truncated); 6: SQL NULL; 7: SQL NULL; 8: len 16; hex <data>; asc <redacted>@yahoo.com;; 9: SQL NULL; 10: len 10; hex <data>; asc <phone>;; 11: len 30; hex <data>; asc android:<id>;...(truncated); 12: len 8; hex <data>; asc    J]  Z;; 13: len 8; hex <data>; asc    J]  Z;; 14: len 8; hex a39410acaa9b4340; asc       C@;; 15: len 8; hex <data>; asc     m S ;; 16: len 2; hex 8ce0; asc   ;; 17: len 8; hex 80000000000004a6; asc         ;; 18: len 4; hex 80000001; asc     ;; 19: len 1; hex 81; asc  ;; 20: len 8; hex <data>; asc    JR   ;; 21: len 8; hex <data>; asc    J]   ;; 22: len 1; hex 80; asc  ;; 23: SQL NULL; 24: SQL NULL;

        *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
        RECORD LOCKS space id 0 page no 11144 n bits 152 index `PRIMARY` of table `family`.`people` trx id 0 45321448 lock_mode X locks rec but not gap waiting
        Record lock, heap no 12 PHYSICAL RECORD: n_fields 25; compact format; info bits 0
        0: len 8; hex 8000000000000c35; asc        5;; 1: len 6; hex 000002b38ce6; asc       ;; 2: len 7; hex 00000002801f89; asc        ;; 3: len 8; hex 800000000000064a; asc        J;; 4: len 4; hex <data>; asc <name>;; 5: len 30; hex <data>; asc <data>;...(truncated); 6: SQL NULL; 7: SQL NULL; 8: len 16; hex <data>; asc <redacted>@yahoo.com;; 9: SQL NULL; 10: len 10; hex <data>; asc <phone>;; 11: len 30; hex <data>; asc android:<id>;...(truncated); 12: len 8; hex <data>; asc    J]  Z;; 13: len 8; hex <data>; asc    J]  Z;; 14: len 8; hex a39410acaa9b4340; asc       C@;; 15: len 8; hex <data>; asc     m S ;; 16: len 2; hex 8ce0; asc   ;; 17: len 8; hex 80000000000004a6; asc         ;; 18: len 4; hex 80000001; asc     ;; 19: len 1; hex 81; asc  ;; 20: len 8; hex <data>; asc    JR   ;; 21: len 8; hex <data>; asc    J]   ;; 22: len 1; hex 80; asc  ;; 23: SQL NULL; 24: SQL NULL;

        *** WE ROLL BACK TRANSACTION (1)

Kami membaca artikel ini pada penguncian tombol berikutnya, tetapi sepertinya tidak berlaku bagi kami karena kami tidak melakukan seleksi untuk pembaruan.

Memperbarui

Pagi ini saya menemukan tanda tangan kebuntuan yang sedikit berbeda yang mungkin menjadi penyebab utama kebuntuan ini. Saya telah diposting kebuntuan itu sebagai pertanyaan terpisah untuk menjaga hal-hal sederhana. Saya akan memperbarui di sini jika saya dapat mengkonfirmasi bahwa pertanyaan lain adalah penyebabnya.

Inilah yang saya lihat

Saya melihat tiga pertanyaan, semuanya hampir identik.

UPDATE people SET company_id = 1610, name = '<name>', password = '<hash>',
temp_password = NULL, reset_password_hash = NULL, email = '<redacted>@yahoo.com',
phone = NULL, mobile = '<phone>', iphone_device_id = 'android:<id>-<id>',
iphone_device_time = '2011-06-06 05:35:09', last_checkin = '2011-06-06 05:24:42',
location_lat = <lat>, location_long = -<lng>, gps_strength = 3296,
picture_blob_id = 1190,authority = 1, active = 1,
date_created = '2011-04-13 20:21:20',
last_login = '2011-06-06 05:35:09', panic_mode = 0, battery_level = NULL,
battery_state = NULL WHERE people_id = 3125;

Perbedaannya

TRANSAKSI 1

iphone_device_time = '2011-06-06 05:24:42', last_checkin = '2011-06-06 05:35:07'

TRANSAKSI 2

iphone_device_time = '2011-06-06 05:35:09', last_checkin = '2011-06-06 05:24:42'

Harap perhatikan bahwa nilai kolom dibalik. Biasanya, kebuntuan terjadi ketika dua transaksi yang berbeda mengakses dua kunci dari dua tabel dengan TX1 (Transaksi 1) mendapatkan baris A dan kemudian baris B sedangkan TX2 mendapatkan baris B dan kemudian baris A. Dalam hal ini, TX1 dan TX2 adalah mengakses baris yang sama tetapi mengubah dua kolom yang berbeda (iphone_device_time, last_checkin).

Nilai-nilai tidak masuk akal. Pada 5:24:42, lapor masuk terakhir adalah 5:35:07. Sepuluh menit dan 27 detik kemudian (5:35:07 - 05:24:42), nilai kolom dibalik.

Pertanyaan besarnya adalah: Mengapa TX1 ditahan selama hampir 11 menit ???

Ini sebenarnya bukan jawaban. Ini hanya bandwidth dan seluruh dari saya. Saya harap pengamatan ini membantu.

UPDATE 2011-06-06 09:57

Silakan periksa tautan ini mengenai innodb_locks_unsafe_for_binlog : Alasan saya menyarankan membaca ini adalah hal lain yang saya lihat di layar STATUS INNODB Anda. Ungkapan lock_mode X (kunci eksklusif) dan lock_mode S (kunci bersama) menunjukkan kedua kunci dikenakan (atau berusaha untuk memaksakan) pada baris yang sama. Mungkin ada beberapa serialisasi internal yang sedang dilakukan penguncian baris berikutnya. Standarnya adalah OFF. Setelah membaca ini, Anda mungkin perlu mempertimbangkan untuk mengaktifkannya.

UPDATE 2011-06-06 10:03

Alasan lain untuk memeriksa alur pemikiran ini adalah kenyataan bahwa semua transaksi melintasi kunci UTAMA. Karena PRIMARY adalah indeks berkerumun di InnoDB, kunci PRIMARY dan baris itu sendiri bersama-sama. Dengan demikian, melintasi baris dan dan KUNCI UTAMA adalah satu dan sama. Oleh karena itu, setiap kunci indeks pada KUNCI UTAMA juga merupakan kunci tingkat baris.

UPDATE 2011-06-06 19:21

Periksa nilai auocommit apa yang Anda miliki . Jika autocommit tidak aktif, saya dapat melihat dua (2) masalah yang mungkin terjadi

1. memperbarui baris yang sama dua kali dalam transaksi yang sama
2. memperbarui baris yang sama dalam dua transaksi berbeda

Faktanya, STATUS SHOW ENGINE INNODB yang Anda tunjukkan dalam pertanyaan memiliki kedua skenario tersebut.

Jawaban Rolando tentu saja membantu kami mendapatkan jalan menuju solusi yang tepat. Namun kami akhirnya tidak menyesuaikan konfigurasi autocommit kami, tingkat isolasi kami atau konfigurasi innodb_locks_unsafe_for_binlog .

Kami yakin log deadlock yang kami posting pada pertanyaan pertama ini adalah hasil dari deadlock yang kami temukan dan posting di sini . Karena kami menyelesaikan masalah dengan dua pertanyaan tersebut, kami tidak melihat adanya deadlock sejak itu.