MySQL InnoDB mengunci kunci primer pada penghapusan bahkan dalam READ COMMITTED

Kata pengantar

Aplikasi kami menjalankan beberapa utas yang menjalankan DELETEkueri secara paralel. Kueri mempengaruhi data yang terisolasi, yaitu seharusnya tidak ada kemungkinan yang DELETEterjadi bersamaan pada baris yang sama dari utas yang terpisah. Namun, per dokumentasi MySQL menggunakan apa yang disebut kunci 'tombol selanjutnya' untuk DELETEpernyataan, yang mengunci kunci yang cocok dan beberapa celah. Hal ini mengarah ke jalan buntu dan satu-satunya solusi yang kami temukan adalah menggunakan READ COMMITTEDtingkat isolasi.

Masalah

Masalah muncul ketika menjalankan DELETEpernyataan kompleks dengan JOINs dari tabel besar. Dalam kasus tertentu, kami memiliki tabel dengan peringatan yang hanya memiliki dua baris, tetapi kueri harus menghapus semua peringatan milik beberapa entitas tertentu dari dua INNER JOINtabel ed yang terpisah . Kueri adalah sebagai berikut:

DELETE pw 
FROM proc_warnings pw 
INNER JOIN day_position dp 
   ON dp.transaction_id = pw.transaction_id 
INNER JOIN ivehicle_days vd 
   ON vd.id = dp.ivehicle_day_id 
WHERE vd.ivehicle_id=? AND dp.dirty_data=1

Ketika tabel day_position cukup besar (dalam kasus pengujian saya ada 1448 baris) maka transaksi apa pun bahkan dengan READ COMMITTEDmode isolasi memblokir seluruh proc_warnings tabel.

Masalah ini selalu direproduksi pada data sampel ini - http://yadi.sk/d/QDuwBtpW1BxB9 baik di MySQL 5.1 (diperiksa pada 5.1.59) dan MySQL 5.5 (diperiksa pada MySQL 5.5.24).

EDIT: Data sampel tertaut juga berisi skema dan indeks untuk tabel kueri, direproduksi di sini untuk kenyamanan:

CREATE TABLE  `proc_warnings` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `transaction_id` int(10) unsigned NOT NULL,
    `warning` varchar(2048) NOT NULL,
    PRIMARY KEY (`id`),
    KEY `proc_warnings__transaction` (`transaction_id`)
);

CREATE TABLE  `day_position` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `transaction_id` int(10) unsigned DEFAULT NULL,
    `sort_index` int(11) DEFAULT NULL,
    `ivehicle_day_id` int(10) unsigned DEFAULT NULL,
    `dirty_data` tinyint(4) DEFAULT NULL,
    PRIMARY KEY (`id`),
    KEY `day_position__trans` (`transaction_id`),
    KEY `day_position__is` (`ivehicle_day_id`,`sort_index`),
    KEY `day_position__id` (`ivehicle_day_id`,`dirty_data`)
) ;

CREATE TABLE  `ivehicle_days` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `d` date DEFAULT NULL,
    `sort_index` int(11) DEFAULT NULL,
    `ivehicle_id` int(10) unsigned DEFAULT NULL,
    PRIMARY KEY (`id`),
    KEY `ivehicle_days__is` (`ivehicle_id`,`sort_index`),
    KEY `ivehicle_days__d` (`d`)
);

Kueri per transaksi adalah sebagai berikut:

• Transaksi 1

  set transaction isolation level read committed;
  set autocommit=0;
  begin;
  DELETE pw 
  FROM proc_warnings pw 
  INNER JOIN day_position dp 
      ON dp.transaction_id = pw.transaction_id 
  INNER JOIN ivehicle_days vd 
      ON vd.id = dp.ivehicle_day_id 
  WHERE vd.ivehicle_id=2 AND dp.dirty_data=1;

• Transaksi 2

  set transaction isolation level read committed;
  set autocommit=0;
  begin;
  DELETE pw 
  FROM proc_warnings pw 
  INNER JOIN day_position dp 
      ON dp.transaction_id = pw.transaction_id 
  INNER JOIN ivehicle_days vd 
      ON vd.id = dp.ivehicle_day_id 
  WHERE vd.ivehicle_id=13 AND dp.dirty_data=1;

Salah satunya selalu gagal dengan kesalahan 'Kunci waktu tunggu tunggu terlampaui ...'. The information_schema.innodb_trxberisi baris berikut:

| trx_id     | trx_state   | trx_started           | trx_requested_lock_id  | trx_wait_started      | trx_wait | trx_mysql_thread_id | trx_query |
| '1A2973A4' | 'LOCK WAIT' | '2012-12-12 20:03:25' | '1A2973A4:0:3172298:2' | '2012-12-12 20:03:25' | '2'      | '3089'              | 'DELETE pw FROM proc_warnings pw INNER JOIN day_position dp ON dp.transaction_id = pw.transaction_id INNER JOIN ivehicle_days vd ON vd.id = dp.ivehicle_day_id WHERE vd.ivehicle_id=13 AND dp.dirty_data=1' |
| '1A296F67' | 'RUNNING'   | '2012-12-12 19:58:02' | NULL                   | NULL | '7' | '3087' | NULL |

information_schema.innodb_locks

| lock_id                | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
| '1A2973A4:0:3172298:2' | '1A2973A4'  | 'X'       | 'RECORD'  | '`deadlock_test`.`proc_warnings`' | '`PRIMARY`' | '0' | '3172298' | '2' | '53' |
| '1A296F67:0:3172298:2' | '1A296F67'  | 'X'       | 'RECORD'  | '`deadlock_test`.`proc_warnings`' | '`PRIMARY`' | '0' | '3172298' | '2' | '53' |

Seperti yang saya lihat, kedua query menginginkan Xkunci eksklusif pada baris dengan primary key = 53. Namun, tidak satu pun dari mereka harus menghapus baris dari proc_warningstabel. Saya hanya tidak mengerti mengapa indeks terkunci. Selain itu, indeks tidak dikunci ketika proc_warningstabel kosong atau day_positiontabel berisi jumlah baris yang lebih sedikit (yaitu seratus baris).

Investigasi lebih lanjut adalah untuk menyelidiki pertanyaan yang EXPLAINsama SELECT. Ini menunjukkan bahwa pengoptimal kueri tidak menggunakan indeks ke proc_warningstabel kueri dan itulah satu-satunya alasan yang dapat saya bayangkan mengapa ia memblokir seluruh indeks kunci primer.

Kasing sederhana

Masalah juga dapat direproduksi dalam kasus yang lebih sederhana ketika hanya ada dua tabel dengan beberapa catatan, tetapi tabel anak tidak memiliki indeks pada kolom ref tabel induk.

Buat parenttabel

CREATE TABLE `parent` (
  `id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB

Buat childtabel

CREATE TABLE `child` (
  `id` int(10) unsigned NOT NULL,
  `parent_id` int(10) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB

Isi tabel

INSERT INTO `parent` (id) VALUES (1), (2);
INSERT INTO `child` (id, parent_id) VALUES (1, NULL), (2, NULL);

Tes dalam dua transaksi paralel:

• Transaksi 1

  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
  SET AUTOCOMMIT=0;
  BEGIN;
  DELETE c FROM child c 
    INNER JOIN parent p ON p.id = c.parent_id 
  WHERE p.id = 1;

• Transaksi 2

  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
  SET AUTOCOMMIT=0;
  BEGIN;
  DELETE c FROM child c 
    INNER JOIN parent p ON p.id = c.parent_id 
  WHERE p.id = 2;

Bagian umum dalam kedua kasus adalah MySQL tidak menggunakan indeks. Saya percaya itulah alasan kunci seluruh meja.

Solusi Kami

Satu-satunya solusi yang dapat kita lihat untuk saat ini adalah meningkatkan batas waktu tunggu kunci default dari 50 detik menjadi 500 detik untuk membiarkan utas selesai berbenah. Kemudian jagalah agar tetap bersilangan.

Setiap bantuan dihargai.

JAWABAN BARU (SQL dinamis gaya MySQL): Oke, yang ini menangani masalah seperti yang dijelaskan oleh salah satu poster lainnya - membalikkan urutan penguncian kunci eksklusif yang saling tidak kompatibel sehingga terlepas dari berapa banyak yang terjadi, hanya terjadi untuk jumlah waktu paling sedikit pada akhir pelaksanaan transaksi.

Ini dilakukan dengan memisahkan bagian baca dari pernyataan menjadi pernyataan pilih sendiri dan secara dinamis menghasilkan pernyataan penghapusan yang akan dipaksa untuk berjalan terakhir karena urutan tampilan pernyataan, dan yang hanya akan memengaruhi tabel proc_warnings.

Demo tersedia di sql fiddle:

Tautan ini menunjukkan skema dengan data sampel, dan kueri sederhana untuk baris yang cocok dengannya ivehicle_id=2. Hasil 2 baris, karena tidak ada satupun yang dihapus.

Tautan ini menunjukkan skema yang sama, sampel data, tetapi meneruskan nilai 2 ke program DeleteEntries disimpan, memberitahu SP untuk menghapus proc_warningsentri untuk ivehicle_id=2. Kueri sederhana untuk baris tidak mengembalikan hasil karena semuanya telah berhasil dihapus. Tautan demo hanya menunjukkan bahwa kode berfungsi sebagaimana dimaksudkan untuk dihapus. Pengguna dengan lingkungan pengujian yang tepat dapat mengomentari apakah ini menyelesaikan masalah utas yang diblokir.

Berikut ini kodenya juga untuk kenyamanan:

CREATE PROCEDURE DeleteEntries (input_vid INT)
BEGIN

    SELECT @idstring:= '';
    SELECT @idnum:= 0;
    SELECT @del_stmt:= '';

    SELECT @idnum:= @idnum+1 idnum_col, @idstring:= CONCAT(@idstring, CASE WHEN CHARACTER_LENGTH(@idstring) > 0 THEN ',' ELSE '' END, CAST(id AS CHAR(10))) idstring_col
    FROM proc_warnings
    WHERE EXISTS (
        SELECT 0
        FROM day_position
        WHERE day_position.transaction_id = proc_warnings.transaction_id
        AND day_position.dirty_data = 1
        AND EXISTS (
            SELECT 0
            FROM ivehicle_days
            WHERE ivehicle_days.id = day_position.ivehicle_day_id
            AND ivehicle_days.ivehicle_id = input_vid
        )
    )
    ORDER BY idnum_col DESC
    LIMIT 1;

    IF (@idnum > 0) THEN
        SELECT @del_stmt:= CONCAT('DELETE FROM proc_warnings WHERE id IN (', @idstring, ');');

        PREPARE del_stmt_hndl FROM @del_stmt;
        EXECUTE del_stmt_hndl;
        DEALLOCATE PREPARE del_stmt_hndl;
    END IF;
END;

Ini adalah sintaks untuk memanggil program dari dalam suatu transaksi:

CALL DeleteEntries(2);

JAWABAN ASLI (masih berpikir itu tidak terlalu buruk) Sepertinya 2 masalah: 1) permintaan lambat 2) perilaku penguncian tak terduga

Mengenai masalah # 1, permintaan lambat sering diselesaikan dengan dua teknik yang sama dalam penyederhanaan pernyataan kueri tandem dan penambahan atau modifikasi yang berguna untuk indeks. Anda sendiri telah membuat koneksi ke indeks - tanpa mereka optimizer tidak dapat mencari set baris terbatas untuk diproses, dan setiap baris dari setiap tabel mengalikan per baris tambahan memindai jumlah pekerjaan tambahan yang harus dilakukan.

DIREVISI SETELAH MELIHAT POS POS DAN SKEMA: Tapi saya kira Anda akan mendapatkan manfaat kinerja paling besar untuk permintaan Anda dengan memastikan Anda memiliki konfigurasi indeks yang baik. Untuk melakukannya, Anda bisa menggunakan kinerja penghapusan yang lebih baik, dan bahkan mungkin kinerja penghapusan yang lebih baik, dengan trade off dari indeks yang lebih besar dan mungkin terasa lebih lambat menyisipkan kinerja pada tabel yang sama dengan yang ditambahkan struktur indeks tambahan.

LEBIH BAIK LEBIH BAIK:

CREATE TABLE  `day_position` (
    ...,
    KEY `day_position__id_rvrsd` (`dirty_data`, `ivehicle_day_id`)

) ;


CREATE TABLE  `ivehicle_days` (
    ...,
    KEY `ivehicle_days__vid_no_sort_index` (`ivehicle_id`)
);

DIREVISI DI SINI TERLALU: Karena ini membutuhkan waktu selama berjalan, saya akan meninggalkan dirty_data dalam indeks, dan saya juga salah ketika memastikannya setelah ivehicle_day_id dalam urutan indeks - seharusnya itu yang pertama.

Tetapi jika saya memiliki tangan saya di atasnya, pada titik ini, karena harus ada jumlah data yang baik untuk membuatnya selama itu, saya hanya akan pergi untuk semua indeks yang meliputi hanya untuk memastikan saya mendapatkan pengindeksan terbaik yang waktu pemecahan masalah saya dapat dibeli, jika tidak ada hal lain untuk mengesampingkan bagian dari masalah tersebut.

INDEKS TERBAIK / PENUTUPAN:

CREATE TABLE  `day_position` (
    ...,
    KEY `day_position__id_rvrsd_trnsid_cvrng` (`dirty_data`, `ivehicle_day_id`, `transaction_id`)
) ;

CREATE TABLE  `ivehicle_days` (
    ...,
    UNIQUE KEY `ivehicle_days__vid_id_cvrng` (ivehicle_id, id)
);

CREATE TABLE  `proc_warnings` (

    .., /*rename primary key*/
    CONSTRAINT pk_proc_warnings PRIMARY KEY (id),
    UNIQUE KEY `proc_warnings__transaction_id_id_cvrng` (`transaction_id`, `id`)
);

Ada dua sasaran pengoptimalan kinerja yang dicari oleh dua saran perubahan terakhir:
1) Jika kunci pencarian untuk tabel yang diakses secara berturut-turut tidak sama dengan hasil kunci yang dikelompokkan yang dikembalikan untuk tabel yang saat ini diakses, kami menghilangkan apa yang seharusnya menjadi kebutuhan untuk membuat set kedua operasi pencarian-dengan-scan indeks
pada indeks berkerumun 2) Jika yang terakhir tidak terjadi, masih ada setidaknya kemungkinan bahwa pengoptimal dapat memilih algoritma bergabung yang lebih efisien karena indeks akan menjaga diperlukan kunci bergabung dalam urutan.

Kueri Anda tampak sesederhana mungkin (disalin di sini jika diedit nanti):

DELETE pw 
FROM proc_warnings pw 
INNER JOIN day_position dp 
    ON dp.transaction_id = pw.transaction_id 
INNER JOIN ivehicle_days vd 
    ON vd.id = dp.ivehicle_day_id 
WHERE vd.ivehicle_id=2 AND dp.dirty_data=1;

Kecuali tentu saja ada sesuatu tentang urutan bergabung tertulis yang memengaruhi cara pengoptimal kueri menghasilkan dalam hal ini Anda dapat mencoba beberapa saran penulisan ulang yang telah diberikan orang lain, termasuk mungkin ini dengan petunjuk indeks (opsional):

DELETE FROM proc_warnings
FORCE INDEX (`proc_warnings__transaction_id_id_cvrng`, `pk_proc_warnings`)
WHERE EXISTS (
    SELECT 0
    FROM day_position
    FORCE INDEX (`day_position__id_rvrsd_trnsid_cvrng`)  
    WHERE day_position.transaction_id = proc_warnings.transaction_id
    AND day_position.dirty_data = 1
    AND EXISTS (
        SELECT 0
        FROM ivehicle_days
        FORCE INDEX (`ivehicle_days__vid_id_cvrng`)  
        WHERE ivehicle_days.id = day_position.ivehicle_day_id
        AND ivehicle_days.ivehicle_id = ?
    )
);

Mengenai # 2, perilaku penguncian yang tidak terduga.

Seperti yang saya lihat, kedua query menginginkan kunci X eksklusif pada satu baris dengan primary key = 53. Namun, keduanya tidak harus menghapus baris dari tabel proc_warnings. Saya hanya tidak mengerti mengapa indeks terkunci.

Saya kira itu akan menjadi indeks yang terkunci karena baris data yang akan dikunci berada dalam indeks berkerumun, yaitu baris tunggal data itu sendiri berada di indeks.

Itu akan dikunci, karena:
1) menurut http://dev.mysql.com/doc/refman/5.1/en/innodb-locks-set.html

... DELETE umumnya menetapkan kunci rekaman pada setiap catatan indeks yang dipindai dalam pemrosesan pernyataan SQL. Tidak masalah apakah ada kondisi WHERE dalam pernyataan yang akan mengecualikan baris. InnoDB tidak ingat persis kondisi WHERE, tetapi hanya tahu rentang indeks mana yang dipindai.

Anda juga menyebutkan di atas:

... bagi saya fitur utama READ COMMITTED adalah bagaimana ia berurusan dengan kunci. Itu harus melepaskan kunci indeks dari baris yang tidak cocok, tetapi tidak.

dan memberikan referensi berikut untuk itu:
http://dev.mysql.com/doc/refman/5.1/en/set-transaction.html#isolevel_read-committed

Yang menyatakan sama dengan Anda, kecuali bahwa menurut referensi yang sama ada suatu kondisi di mana kunci harus dilepaskan:

Juga, kunci rekaman untuk baris yang tidak cocok dilepaskan setelah MySQL telah mengevaluasi kondisi WHERE.

Yang diulangi juga di halaman manual ini http://dev.mysql.com/doc/refman/5.1/en/innodb-record-level-locks.html

Ada juga efek lain dari menggunakan tingkat isolasi READ COMMITTED atau mengaktifkan innodb_locks_unsafe_for_binlog: Kunci rekaman untuk baris yang tidak cocok dilepaskan setelah MySQL telah mengevaluasi kondisi WHERE.

Jadi, kami diberitahu bahwa kondisi WHERE harus dievaluasi sebelum kunci dapat dilepaskan. Sayangnya kami tidak diberi tahu kapan kondisi WHERE dievaluasi dan mungkin akan ada sesuatu yang berubah dari satu paket ke paket lain yang dibuat oleh pengoptimal. Tapi itu memberitahu kita bahwa rilis kunci, entah bagaimana tergantung pada kinerja eksekusi permintaan, optimasi yang seperti yang kita bahas di atas tergantung pada penulisan pernyataan yang cermat, dan penggunaan indeks secara bijaksana. Ini juga dapat ditingkatkan dengan desain tabel yang lebih baik, tetapi itu mungkin akan menjadi pertanyaan terbaik.

Selain itu, indeks juga tidak dikunci saat tabel proc_warnings kosong

Basis data tidak dapat mengunci catatan dalam indeks jika tidak ada.

Selain itu, indeks tidak dikunci ketika ... tabel day_position berisi lebih sedikit jumlah baris (yaitu seratus baris).

Ini bisa berarti banyak hal seperti tetapi mungkin tidak terbatas pada: rencana eksekusi yang berbeda karena perubahan statistik, kunci yang terlalu singkat untuk diamati karena eksekusi yang jauh lebih cepat karena kumpulan data yang jauh lebih kecil / bergabung dengan operasi.

Saya dapat melihat bagaimana READ_COMMITTED dapat menyebabkan situasi ini.

READ_COMMITTED memungkinkan untuk tiga hal:

• Visibilitas perubahan yang dilakukan oleh transaksi lain menggunakan READ_COMMITTED tingkat isolasi.
• Non-Repeatable Reads: Transaksi melakukan pengambilan yang sama dengan kemungkinan mendapatkan hasil yang berbeda setiap kali.
• Hantu: Transaksi mungkin memiliki baris muncul di tempat itu tidak terlihat sebelumnya.

Ini menciptakan paradigma internal untuk transaksi itu sendiri karena transaksi harus mempertahankan kontak dengan:

• InnoDB Buffer Pool (sementara commit masih belum rata)
• Kunci Utama Tabel
• Mungkin
  • Penyangga Tulis Ganda
  • Batalkan Tablespace
• Representasi Bergambar

Jika dua transaksi READ_COMMITTED yang berbeda mengakses tabel / baris yang sama yang sedang diperbarui dengan cara yang sama, bersiaplah untuk berharap bukan kunci tabel, tetapi kunci eksklusif dalam gen_clust_index (alias Clustered Index) . Diberi pertanyaan dari case sederhana Anda:

• Transaksi 1

  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
  SET AUTOCOMMIT=0;
  BEGIN;
  DELETE c FROM child c 
    INNER JOIN parent p ON p.id = c.parent_id 
  WHERE p.id = 1;

• Transaksi 2

  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
  SET AUTOCOMMIT=0;
  BEGIN;
  DELETE c FROM child c 
    INNER JOIN parent p ON p.id = c.parent_id 
  WHERE p.id = 2;

Anda mengunci lokasi yang sama di gen_clust_index. Orang mungkin berkata, "tetapi setiap transaksi memiliki kunci utama yang berbeda.". Sayangnya, ini bukan kasus di mata InnoDB. Kebetulan bahwa id 1 dan id 2 berada di halaman yang sama.

Lihat kembali yang information_schema.innodb_locksAnda berikan dalam Pertanyaan

| lock_id                | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
| '1A2973A4:0:3172298:2' | '1A2973A4'  | 'X'       | 'RECORD'  | '`deadlock_test`.`proc_warnings`' | '`PRIMARY`' | '0' | '3172298' | '2' | '53' |
| '1A296F67:0:3172298:2' | '1A296F67'  | 'X'       | 'RECORD'  | '`deadlock_test`.`proc_warnings`' | '`PRIMARY`' | '0' | '3172298' | '2' | '53' |

Dengan pengecualian lock_id,, lock_trx_iddeskripsi kunci lainnya identik. Karena transaksi berada pada level bermain yang sama (isolasi transaksi yang sama), ini memang harus terjadi .

Percayalah, saya telah membahas situasi semacam ini sebelumnya. Inilah posting saya yang lalu tentang ini:

• Nov 05, 2012: Bagaimana cara menganalisis status innodb pada kebuntuan dalam menyisipkan Query?
• Aug 08, 2011: Apakah InnoDB Deadlock eksklusif untuk INSERT / UPDATE / DELETE?
• Jun 14, 2011: Alasan terkadang permintaan lambat?
• Jun 08, 2011: Apakah dua pertanyaan ini akan menghasilkan jalan buntu jika dieksekusi secara berurutan?
• Jun 06, 2011: Masalah menguraikan kebuntuan dalam log status innodb

Saya melihat pertanyaan dan menjelaskannya. Saya tidak yakin, tetapi punya firasat, bahwa masalahnya adalah sebagai berikut. Mari kita lihat kueri:

DELETE pw 
FROM proc_warnings pw 
INNER JOIN day_position dp 
   ON dp.transaction_id = pw.transaction_id 
INNER JOIN ivehicle_days vd 
   ON vd.id = dp.ivehicle_day_id 
WHERE vd.ivehicle_id=? AND dp.dirty_data=1;

SELECT yang setara adalah:

SELECT pw.id
FROM proc_warnings pw
INNER JOIN day_position dp
   ON dp.transaction_id = pw.transaction_id
INNER JOIN ivehicle_days vd
   ON vd.id = dp.ivehicle_day_id
WHERE vd.ivehicle_id=16 AND dp.dirty_data=1;

Jika Anda melihat penjelasannya, Anda akan melihat bahwa rencana eksekusi dimulai dengan proc_warningstabel. Itu berarti bahwa MySQL memindai kunci utama dalam tabel dan untuk setiap baris memeriksa apakah kondisinya benar, dan jika benar - baris dihapus. Artinya MySQL harus mengunci seluruh kunci primer.

Yang Anda butuhkan adalah untuk membalikkan urutan GABUNG, yaitu menemukan semua id transaksi dengan vd.ivehicle_id=16 AND dp.dirty_data=1dan bergabung dengan mereka di atas proc_warningsmeja.

Anda harus menambal salah satu indeks:

ALTER TABLE `day_position`
 DROP INDEX `day_position__id`,
 ADD INDEX `day_position__id`
   USING BTREE (`ivehicle_day_id`, `dirty_data`, `transaction_id`);

dan tulis ulang kueri penghapusan:

DELETE pw
FROM (
  SELECT DISTINCT dp.transaction_id
  FROM ivehicle_days vd
  JOIN day_position dp ON dp.ivehicle_day_id = vd.id
  WHERE vd.ivehicle_id=? AND dp.dirty_data=1
) as tr_id
JOIN proc_warnings pw ON pw.transaction_id = tr_id.transaction_id;

Ketika Anda mengatur tingkat transaksi tanpa cara Anda melakukannya berlaku Baca Komit untuk transaksi berikutnya saja, dengan demikian (setel komit otomatis). Ini berarti setelah autocommit = 0, Anda tidak lagi di Komit Baca. Saya akan menulis seperti ini:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
DELETE c FROM child c
INNER JOIN parent p ON
    p.id = c.parent_id
WHERE p.id = 1;

Anda dapat memeriksa tingkat isolasi apa yang Anda masuki dengan menanyakan

SELECT @@tx_isolation;