Apa yang dibaca oleh Phantom dan bagaimana InnoDB menghalang mereka (kunci seterusnya)?

InnoDB berkesan menghalang pembacaan hantu melalui mekanisme penguncian utama. 1) Pengunci kunci seterusnya menggabungkan kunci baris dan kunci jurang untuk mengunci rekod dan jurang mereka untuk mengelakkan rekod baru daripada dimasukkan. 2) Dalam aplikasi praktikal, dengan mengoptimumkan pertanyaan dan menyesuaikan tahap pengasingan, persaingan kunci dapat dikurangkan dan prestasi konkurensi dapat ditingkatkan.

Pengenalan

Di dunia pangkalan data, hantu berbunyi adalah seperti kewujudan hantu, diam -diam tetapi boleh menyebabkan masalah yang tidak dijangka. Hari ini kita akan membincangkan sifat bacaan fantasi dan bagaimana InnoDB menghalang fenomena ini melalui mekanisme penguncian utama. Melalui artikel ini, anda bukan sahaja akan memahami definisi dan bahaya bacaan ilusi, tetapi juga mendapat pemahaman yang mendalam tentang bagaimana mekanisme kunci InnoDB memastikan konsistensi data.

Semak pengetahuan asas

Sebelum membincangkan bacaan fantasi, kita perlu memahami beberapa konsep asas terlebih dahulu. Transaksi adalah unit asas operasi pangkalan data, yang memastikan atom, konsistensi, pengasingan dan kegigihan (asid) siri operasi. Tahap pengasingan adalah mekanisme yang digunakan untuk mengawal penglihatan antara urus niaga. Yang biasa termasuk membaca yang tidak komited, membaca bacaan yang komited, berulang dan bersiri.

InnoDB adalah enjin penyimpanan untuk MySQL, yang menyokong penguncian peringkat baris, yang bermaksud ia dapat mengunci baris individu dan bukannya keseluruhan jadual, dengan itu meningkatkan prestasi konkurensi.

Konsep teras atau analisis fungsi

Definisi dan fungsi bacaan ilusi

Pembacaan Phantom merujuk kepada mengembalikan set hasil yang berbeza apabila pertanyaan yang sama dilaksanakan pada titik yang berbeza dalam masa dalam transaksi. Ini biasanya berlaku dalam persekitaran berbilang pengguna, apabila satu transaksi dilaksanakan, transaksi lain memasukkan baris baru atau memadamkan baris yang sedia ada, menyebabkan hasil pertanyaan dari transaksi sebelumnya berubah.

Sebagai contoh, katakan Transaksi A melakukan pertanyaan pelbagai untuk mencari semua produk yang berharga kurang daripada $ 100. Semasa pelaksanaan transaksi A, Transaksi B memasukkan rekod baru untuk $ 50. Apabila Transaksi A melaksanakan pertanyaan yang sama sekali lagi, ia akan menemui rekod yang tidak wujud sebelum ini, iaitu bacaan hantu.

Bagaimana ia berfungsi

Sebab utama kejadian pembacaan fantasi adalah bahawa tahap pengasingan transaksi tidak cukup tinggi. Pembacaan hantu adalah mungkin pada tahap pengasingan di mana bacaan tidak diserahkan dan dibaca telah dikemukakan. Dan pada tahap pengasingan bacaan dan siri yang berulang, pangkalan data akan mengambil langkah -langkah untuk mencegah bacaan hantu.

InnoDB menghalang pembacaan hantu melalui penguncian kunci seterusnya. Pengunci kunci seterusnya adalah mekanisme penguncian yang menggabungkan kunci baris dan kunci jurang. Ia bukan sahaja mengunci rekod itu sendiri, tetapi juga jurang antara rekod, dengan itu menghalang urus niaga lain daripada memasukkan rekod baru dalam jurang ini.

Mari kita lihat contoh mudah untuk menggambarkan bagaimana penguncian kunci seterusnya berfungsi:

 - Transaksi a
Memulakan transaksi;
Pilih * dari produk di mana harga <100 untuk kemas kini;

- Transaksi b
Memulakan transaksi;
Masukkan ke dalam produk (nama, harga) nilai (&#39;produk baru&#39;, 50);

Apabila Transaksi A melaksanakan pernyataan pilih, InnoDB mengunci semua rekod dengan harga kurang daripada 100 dan jurang antara rekod ini. Dengan cara ini, Transaksi B tidak dapat memasukkan rekod baru dalam jurang ini, dengan itu mengelakkan bacaan hantu.

Contoh penggunaan

Penggunaan asas

Mari kita lihat contoh yang lebih spesifik bagaimana InnoDB menggunakan kunci seterusnya untuk mengelakkan bacaan hantu:

 - Transaksi a
Memulakan transaksi;
Pilih * dari pesanan di mana jumlah> 1000 untuk kemas kini;

- Transaksi b
Memulakan transaksi;
Masukkan ke dalam pesanan (customer_id, amaun) nilai (1, 1500);

Dalam contoh ini, transaksi A mengunci semua pesanan dengan jumlah yang lebih besar daripada 1000 dan jurangnya di antara mereka, dan Transaksi B cuba memasukkan pesanan baru, tetapi ia akan disekat sehingga transaksi A melakukan atau gulung kembali.

Penggunaan lanjutan

Dalam sesetengah kes, kita mungkin memerlukan kunci kawalan yang lebih baik. Sebagai contoh, jika kita mahu mengunci hanya rekod dalam julat tertentu, kita boleh menggunakan pernyataan kunci yang jelas:

 - Transaksi a
Memulakan transaksi;
Pilih * dari inventori di mana kuantiti> 10 dan kuantiti <20 untuk kemas kini;

- Transaksi b
Memulakan transaksi;
Kemas kini kuantiti set inventori = kuantiti - 1 di mana item_id = 15;

Dalam contoh ini, transaksi A mengunci rekod dengan inventori antara 10 dan 20 dan jurangnya, dan Transaksi B cuba untuk mengemas kini rekod dengan inventori 15, tetapi akan disekat sehingga transaksi A melakukan atau gulung kembali.

Kesilapan biasa dan tip debugging

Kesilapan biasa apabila menggunakan penguncian kunci seterusnya termasuk tamat masa menunggu kunci dan kebuntuan. Tamat masa menunggu kunci berlaku apabila urus niaga menunggu masa kunci melebihi masa tamat yang ditetapkan, sementara kebuntuan berlaku apabila dua atau lebih transaksi menunggu satu sama lain untuk melepaskan kunci.

Untuk menyahpepijat masalah ini, anda boleh menggunakan kaedah berikut:

• Gunakan perintah SHOW ENGINE INNODB STATUS untuk melihat status kunci semasa dan maklumat kebuntuan.
• Laraskan parameter innodb_lock_wait_timeout untuk meningkatkan masa tamat masa menunggu.
• Gunakan parameter innodb_deadlock_detect untuk membolehkan atau melumpuhkan pengesanan kebuntuan.

Pengoptimuman prestasi dan amalan terbaik

Dalam aplikasi praktikal, pengunci kunci seterusnya mungkin mempunyai kesan prestasi kerana ia meningkatkan overhead mengunci. Berikut adalah beberapa pengoptimuman dan amalan terbaik:

• Kurangkan pelbagai kunci dan kunci hanya rekod dan jurang yang diperlukan.
• Pengunci optimis digunakan untuk mengurangkan penggunaan kunci, seperti mengesan konflik serentak melalui nombor versi.
• Tetapkan tahap pengasingan yang munasabah, pilih tahap pengasingan yang sesuai mengikut keperluan aplikasi, dan elakkan penguncian yang tidak perlu.

Dalam pengalaman projek sebenar saya, saya telah menemui sistem pengurusan inventori platform e-dagang. Oleh kerana kemas kini dan pertanyaan inventori yang kerap, ia telah menyebabkan masalah persaingan kunci yang serius. Dengan mengoptimumkan pernyataan pertanyaan dan menyesuaikan tahap pengasingan, kami berjaya mengurangkan masa menunggu kunci dan meningkatkan prestasi konkurensi sistem.

Secara umum, pemahaman dan penggunaan penguncian kunci seterusnya adalah kunci untuk memastikan konsistensi transaksi pangkalan data. Saya harap artikel ini dapat membantu anda menguasai teknologi ini dengan lebih baik dan mengelakkan masalah yang disebabkan oleh bacaan hantu dalam aplikasi praktikal.

Atas ialah kandungan terperinci Apa yang dibaca oleh Phantom dan bagaimana InnoDB menghalang mereka (kunci seterusnya)?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!