Cara memastikan ketekalan dan keberkesanan akses serentak kepada data ialah masalah yang mesti diselesaikan oleh semua pangkalan data konflik Kunci juga merupakan faktor penting yang mempengaruhi prestasi capaian serentak kepada faktor pangkalan data. Dari perspektif ini, kunci amat penting dan kompleks untuk pangkalan data.
Gambaran keseluruhan kunci MySQL
Berbanding dengan pangkalan data lain, mekanisme penguncian MySQL agak mudah. Ciri yang paling ketara ialah enjin storan yang berbeza menyokong mekanisme penguncian yang berbeza.
Contohnya,
Enjin storan MyISAM dan MEMORY menggunakan penguncian aras meja.
Enjin storan InnoDB menyokong penguncian peringkat baris dan penguncian peringkat meja, tetapi penguncian peringkat baris digunakan secara lalai.
Ciri-ciri ketiga-tiga kunci ini dalam MySQL boleh diringkaskan secara kasar seperti berikut
Kunci peringkat jadual: overhed rendah, penguncian cepat tiada jalan buntu, kebarangkalian konflik kunci yang paling tinggi; tahap keselarasan yang paling rendah.
Kunci peringkat baris: overhed tinggi, penguncian perlahan mungkin berlaku;
Kunci halaman: Kos dan masa mengunci adalah antara kunci meja dan kunci baris akan berlaku;
Hanya dari perspektif kunci: kunci peringkat jadual lebih sesuai untuk aplikasi berasaskan pertanyaan dengan hanya sejumlah kecil data dikemas kini mengikut keadaan indeks, seperti aplikasi Web manakala kunci peringkat baris lebih banyak sesuai untuk aplikasi dengan bilangan pertanyaan yang banyak. Keadaan indeks mengemas kini sejumlah kecil data yang berbeza secara serentak, dan terdapat aplikasi pertanyaan serentak, seperti beberapa sistem pemprosesan transaksi dalam talian (OLTP). Dalam bahagian berikut, kami menumpukan pada isu kunci jadual MySQL dan kunci baris InnoDB.
Kunci meja MyISAM
Enjin storan MyISAM hanya menyokong kunci meja, yang juga merupakan satu-satunya jenis kunci yang disokong dalam beberapa versi pertama MySQL. Dengan peningkatan berterusan keperluan aplikasi untuk integriti transaksi dan keselarasan, MySQL mula membangunkan enjin storan berasaskan transaksi Kemudian, enjin storan BDB yang menyokong kunci halaman dan enjin storan InnoDB yang menyokong kunci baris muncul secara beransur-ansur (sebenarnya InnoDB adalah berasingan. Sebuah syarikat yang kini telah diambil alih oleh Oracle). Walau bagaimanapun, kunci meja MyISAM masih merupakan jenis kunci yang paling banyak digunakan. Bahagian ini akan memperkenalkan penggunaan kunci meja MyISAM secara terperinci.
Pertanyaan pertikaian kunci peringkat jadual
Anda boleh menganalisis pertikaian kunci jadual pada sistem dengan menyemak pembolehubah status table_locks_waited dan table_locks_immediate:
mysql> ';
|. Nilai_pembolehubah |
|Meja_kunci_segera |
|0 set_kunci_jadual |.
Operasi tulis jadual MyISAM akan disekat permintaan pengguna lain untuk jadual yang sama Operasi baca dan tulis jadual
Operasi baca dan tulis jadual MyISAM, serta operasi tulis, adalah bersiri; mengunci pada meja, ia hanya boleh memegang kunci Benang boleh melakukan operasi kemas kini di atas meja. Operasi baca dan tulis daripada utas lain akan menunggu sehingga kunci dilepaskan.
Dapatkan kunci WRITE dari table film_text
mysql> lock table film_text write;
Soalan OK, 0 baris terjejas (0.00 saat)
Pasangan sesi semasa Operasi pertanyaan, kemas kini dan sisipan jadual yang dikunci boleh dilakukan:
mysql> pilih film_id, judul dari teks_filem di mana film_id = 1001;
| tajuk_filem |mysql> kemas kini tajuk set_teks = 'Ujian' di mana film_id = 1001;
Pertanyaan OK, 0 baris terjejas (0.00 saat)
Menunggu
Sesi2 untuk mendapatkan kunci, pertanyaan kembali:
mysql> teks_filem di mana film_id = 1001;
| tajuk_filem ||. 1001 |. Ujian |
1 baris dalam set (57.59 saat)
Bagaimana untuk menambah kunci meja?
MyISAM akan menambah kunci baca secara automatik pada semua jadual yang terlibat sebelum melaksanakan pernyataan pertanyaan (PILIH), dan secara automatik akan menambah kunci tulis pada jadual yang terlibat sebelum melakukan operasi kemas kini (KEMASKINI, PADAM, INSERT, dll.) , proses ini tidak memerlukan campur tangan pengguna, oleh itu, pengguna secara amnya tidak perlu terus menggunakan arahan LOCK TABLE untuk mengunci jadual MyISAM secara eksplisit. Dalam contoh, penguncian eksplisit pada asasnya dilakukan untuk kemudahan dan tidak diperlukan.
Penguncian paparan jadual MyISAM secara amnya adalah untuk mensimulasikan operasi urus niaga pada tahap tertentu dan mencapai bacaan berbilang jadual yang konsisten pada masa tertentu. Sebagai contoh, terdapat pesanan jadual pesanan, yang merekodkan jumlah jumlah setiap pesanan, dan terdapat juga butiran pesanan jadual_perincian, yang merekodkan jumlah kecil setiap produk bagi setiap pesanan. Untuk menyemak sama ada jumlah amaun sepadan, anda mungkin perlu melaksanakan dua SQL berikut:
Pilih jumlah(jumlah) daripada pesanan;
Pilih jumlah(subtotal) daripada order_detail;
Pada masa ini, jika kedua-dua jadual tidak dikunci terlebih dahulu, keputusan yang salah mungkin berlaku, kerana jadual butiran_perintah mungkin telah berubah semasa pelaksanaan pernyataan pertama. Oleh itu, kaedah yang betul hendaklah:
Kunci jadual pesanan dibaca setempat, order_detail dibaca setempat;
Pilih jumlah(jumlah) daripada pesanan;
Pilih jumlah(subjumlah) daripada order_detail;
Buka kunci jadual;
Dua perkara berikut perlu diberi perhatian khususnya.
Contoh di atas menambah pilihan "tempatan" apabila LOCK TABLES Fungsinya adalah untuk membenarkan pengguna lain memasukkan rekod secara serentak di hujung jadual apabila syarat sisipan serentak jadual MyISAM dipenuhi sisipan jadual MyISAM Masalahnya akan diperkenalkan kemudian.
Apabila menggunakan LOCK TABLES untuk menambahkan kunci jadual secara eksplisit pada jadual, semua kunci yang terlibat dalam jadual mesti diperoleh pada masa yang sama dan MySQL tidak menyokong peningkatan kunci. Maksudnya, selepas melaksanakan LOCK TABLES, anda hanya boleh mengakses jadual yang dikunci secara eksplisit, tetapi bukan jadual yang tidak dikunci pada masa yang sama, jika anda menambah kunci baca, anda hanya boleh melakukan operasi pertanyaan, tetapi tidak mengemas kini operasi. Sebenarnya, ini pada asasnya berlaku dalam kes penguncian automatik MyISAM sentiasa memperoleh semua kunci yang diperlukan oleh pernyataan SQL sekaligus. Inilah sebabnya mengapa jadual MyISAM tidak akan menemui jalan buntu (Deadlock Free).
Sesi menggunakan perintah LOCK TABLE untuk menambah kunci baca pada film_text Sesi ini boleh menanyakan rekod dalam jadual yang dikunci, tetapi ralat akan digesa semasa mengemas kini atau mengakses jadual lain pada masa yang sama masa, sesi lain boleh menanyakan rekod dalam jadual, tetapi akan ada kunci menunggu apabila mengemas kini.
Apabila menggunakan LOCK TABLES, bukan sahaja anda perlu mengunci semua jadual yang digunakan serentak, tetapi juga, berapa kali jadual yang sama muncul dalam pernyataan SQL, anda mesti menguncinya melalui alias yang sama seperti dalam Pernyataan SQL Jika tidak, Kesilapan juga boleh berlaku!
Contohnya adalah seperti berikut.
(1) Dapatkan kunci baca pada meja pelakon:
mysql> pelakon jadual kunci dibaca;
Soalan OK, 0 baris terjejas (0.00 saat)
(2) Walau bagaimanapun, mengakses melalui alias akan menyebabkan ralat:
mysql> pilih a.first_name,a.last_name,b.first_name,b.last_name daripada pelakon a,actor b di mana a.first_name = b.first_name and a.first_name = 'Lisa' and a.last_name = 'Tom' and a.last_name b.last_name;
ERROR 1100 (HY000): Jadual 'a' bukan dikunci dengan LOCK TABLES
(3) Alias perlu dikunci secara berasingan:
mysql> pelakon meja kunci sebagai dibaca, pelakon sebagai b dibaca;
Pertanyaan OK, 0 baris terjejas (0.00 saat )
(4) Pertanyaan mengikut alias boleh dilaksanakan dengan betul:
mysql> pilih a.first_name,a.last_name,b.first_name,b.last_name daripada pelakon a,pelakon b di mana a .first_name = b.first_name dan a.first_name = 'Lisa' and a.last_name = 'Tom' and a.last_name b.last_name;
|. nama_pertama |. nama_pertama |
1 baris dalam set (0.00 saat)
Sisipan Serentak
Seperti yang dinyatakan di atas, bacaan dan penulisan jadual MyISAM adalah bersiri, tetapi ini adalah keseluruhan Dari segi. Di bawah keadaan tertentu, jadual MyISAM juga menyokong operasi pertanyaan dan sisipan serentak.
Enjin storan MyISAM mempunyai pembolehubah sistem concurrent_insert, yang digunakan secara khusus untuk mengawal kelakuan sisipan serentaknya masing-masing boleh menjadi 0, 1 atau 2.
Apabila concurrent_insert ditetapkan kepada 0, concurrent insert tidak dibenarkan.
Apabila concurrent_insert ditetapkan kepada 1, jika tiada lubang dalam jadual MyISAM (iaitu, tiada baris yang dipadam di tengah jadual), MyISAM membenarkan satu proses untuk membaca jadual manakala proses lain memasukkan rekod dari hujung jadual. Ini juga tetapan lalai untuk MySQL.
Apabila concurrent_insert ditetapkan kepada 2, rekod dibenarkan untuk dimasukkan serentak di hujung jadual tanpa mengira sama ada terdapat lubang dalam jadual MyISAM.
Anda boleh menggunakan ciri sisipan serentak enjin storan MyISAM untuk menyelesaikan pertikaian kunci untuk pertanyaan dan sisipan ke dalam jadual yang sama dalam aplikasi anda. Sebagai contoh, menetapkan pembolehubah sistem concurrent_insert kepada 2 sentiasa membenarkan pemasukan serentak pada masa yang sama, penyataan OPTIMIZE TABLE secara kerap dilaksanakan semasa tempoh melahu sistem untuk menyahfragmentasi ruang dan memulihkan lubang perantaraan yang disebabkan oleh pemadaman rekod. Untuk pengenalan terperinci kepada pernyataan OPTIMIZE TABLE, sila rujuk bahagian "Dua Kaedah Pengoptimuman Mudah dan Praktikal" dalam Bab 18.
Penjadualan kunci MyISAM
Seperti yang dinyatakan sebelum ini, kunci baca dan tulis enjin storan MyISAM adalah saling eksklusif, dan operasi baca dan tulis adalah bersiri. Jadi, jika satu proses meminta kunci baca pada jadual MyISAM, dan pada masa yang sama proses lain juga meminta kunci tulis pada jadual yang sama, bagaimanakah MySQL mengendalikannya? Jawapannya ialah proses menulis memperoleh kunci terlebih dahulu. Bukan itu sahaja, walaupun permintaan baca tiba dalam baris gilir menunggu kunci dahulu dan permintaan tulis tiba kemudian, kunci tulis akan dimasukkan sebelum permintaan kunci baca! Ini kerana MySQL menganggap permintaan tulis pada umumnya lebih penting daripada permintaan baca. Inilah sebabnya mengapa jadual MyISAM tidak sesuai untuk aplikasi dengan sejumlah besar operasi kemas kini dan operasi pertanyaan, kerana sejumlah besar operasi kemas kini akan menyukarkan operasi pertanyaan untuk mendapatkan kunci baca, yang mungkin menyekat selama-lamanya. Keadaan ini boleh menjadi sangat teruk kadang-kadang! Nasib baik, kami boleh melaraskan tingkah laku penjadualan MyISAM melalui beberapa tetapan.
Dengan menyatakan parameter permulaan kemas kini keutamaan rendah, enjin MyISAM memberi keutamaan untuk membaca permintaan secara lalai.
Dengan melaksanakan arahan SET LOW_PRIORITY_UPDATES=1, keutamaan permintaan kemas kini yang dikeluarkan oleh sambungan ini dikurangkan.
Kurangkan keutamaan INSERT, UPDATE dan DELETE pernyataan dengan menyatakan atribut LOW_PRIORITY bagi pernyataan tersebut.
Walaupun ketiga-tiga kaedah di atas adalah sama ada kemas kini dahulu atau pertanyaan dahulu, ia masih boleh digunakan untuk menyelesaikan masalah serius menunggu kunci baca dalam aplikasi yang membuat pertanyaan agak penting (seperti sistem log masuk pengguna).
Selain itu, MySQL juga menyediakan kaedah kompromi untuk melaraskan konflik baca dan tulis, iaitu, menetapkan nilai yang sesuai untuk parameter sistem max_write_lock_count Apabila kunci baca jadual mencapai nilai ini, MySQL akan buat sementara waktu keutamaan permintaan tulis dikurangkan, memberikan proses membaca peluang tertentu untuk mendapatkan kunci.
Masalah dan penyelesaian yang disebabkan oleh mekanisme penjadualan keutamaan tulis telah dibincangkan di atas. Satu lagi perkara harus ditekankan di sini: beberapa operasi pertanyaan yang memerlukan masa berjalan yang lama juga akan "kebuluran" proses penulisan! Oleh itu, anda harus cuba mengelakkan operasi pertanyaan yang berjalan lama dalam aplikasi anda Jangan selalu cuba menggunakan pernyataan SELECT untuk menyelesaikan masalah, kerana pernyataan SQL yang kelihatan pintar ini selalunya lebih kompleks dan mengambil masa yang lebih lama untuk dilaksanakan. Pernyataan SQL boleh "diuraikan" pada tahap tertentu dengan menggunakan jadual perantaraan dan langkah lain supaya setiap langkah pertanyaan dapat diselesaikan dalam masa yang lebih singkat, dengan itu mengurangkan konflik kunci. Jika pertanyaan kompleks tidak dapat dielakkan, mereka harus dijadualkan untuk dilaksanakan semasa tempoh terbiar pangkalan data Contohnya, beberapa statistik biasa boleh dijadualkan untuk dilaksanakan pada waktu malam.
Kunci InnoDB
Perbezaan terbesar antara InnoDB dan MyISAM ialah dua perkara: satu ialah ia menyokong urus niaga (TRANSAKSI); yang lain ialah ia menggunakan kunci peringkat baris. Terdapat banyak perbezaan antara kunci peringkat baris dan kunci peringkat meja Selain itu, pengenalan transaksi juga membawa beberapa masalah baharu. Mari kita perkenalkan beberapa pengetahuan latar belakang dahulu, dan kemudian bincangkan isu kunci InnoDB secara terperinci.
1. Transaksi (Transaksi) dan atribut ACIDnya
Transaksi ialah unit pemprosesan logik yang terdiri daripada satu set pernyataan SQL Transaksi mempunyai 4 atribut berikut, yang biasanya dirujuk sebagai atribut ACID urus niaga.
(Atomicity) Atomicity: Transaksi ialah unit operasi atom dan semua pengubahsuaian pada data sama ada dilaksanakan atau tidak dilaksanakan langsung.
(Konsisten) Konsisten: Data mesti kekal konsisten pada permulaan dan penyelesaian transaksi. Ini bermakna semua peraturan data yang berkaitan mesti digunakan pada pengubahsuaian transaksi untuk mengekalkan integriti data pada akhir transaksi, semua struktur data dalaman (seperti indeks B-tree atau senarai berganda) juga mesti betul.
(Pengasingan): Sistem pangkalan data menyediakan mekanisme pengasingan tertentu untuk memastikan transaksi dilaksanakan dalam persekitaran "bebas" yang tidak terjejas oleh operasi serentak luaran. Ini bermakna keadaan perantaraan semasa transaksi tidak dapat dilihat oleh dunia luar, dan sebaliknya.
(Tahan Lama) Ketahanan: Selepas urus niaga selesai, pengubahsuaiannya pada data adalah kekal dan boleh dikekalkan walaupun kegagalan sistem berlaku.
Pindahan bank ialah contoh biasa transaksi.
2. Masalah yang disebabkan oleh pemprosesan transaksi serentak
Berbanding dengan pemprosesan bersiri, pemprosesan urus niaga serentak boleh meningkatkan penggunaan sumber pangkalan data dan meningkatkan pemprosesan transaksi sistem pangkalan data, sekali gus menyokong lebih ramai pengguna. Walau bagaimanapun, pemprosesan transaksi serentak juga akan membawa beberapa masalah, terutamanya termasuk situasi berikut.
Kemas Kini Hilang: Apabila dua atau lebih transaksi memilih baris yang sama dan kemudian mengemas kini baris berdasarkan nilai asal yang dipilih, kerana setiap transaksi tidak mengetahui kewujudan transaksi lain, akan ada kemas kini yang hilang masalah berlaku - kemas kini terakhir menimpa kemas kini yang dibuat oleh transaksi lain. Sebagai contoh, dua editor membuat salinan elektronik dokumen yang sama. Setiap editor secara bebas menukar salinan mereka dan kemudian menyimpan salinan yang diubah, menimpa dokumen asal. Editor yang terakhir menyimpan salinan perubahannya menimpa perubahan yang dibuat oleh editor lain. Masalah ini boleh dielakkan jika seorang editor tidak dapat mengakses fail yang sama sehingga editor lain selesai dan melakukan transaksi.
Bacaan Kotor: Transaksi sedang mengubahsuai rekod Sebelum urus niaga selesai dan diserahkan, data rekod ini berada dalam keadaan tidak konsisten pada masa ini, transaksi lain juga berbunyi Jika rekod yang sama tidak dikawal dan transaksi kedua membaca data "kotor" dan melakukan pemprosesan selanjutnya berdasarkannya, kebergantungan data yang tidak terikat akan berlaku. Fenomena ini dengan jelas dipanggil "bacaan kotor".
Bacaan Tidak Boleh Diulang: Transaksi membaca semula data yang dibaca sebelum ini pada suatu masa selepas membaca beberapa data, hanya untuk mendapati bahawa data yang dibacanya telah berubah atau beberapa rekod telah dipadamkan. Fenomena ini dipanggil "bacaan tidak boleh diulang".
Bacaan Hantu: Transaksi membaca semula data yang diambil sebelum ini mengikut syarat pertanyaan yang sama, hanya untuk mendapati transaksi lain telah memasukkan data baharu yang memenuhi syarat pertanyaannya Fenomena ini dipanggil "bacaan hantu".
3. Tahap pengasingan transaksi
Antara masalah yang disebabkan oleh pemprosesan transaksi serentak yang disebutkan di atas, "kehilangan kemas kini" biasanya harus dielakkan sepenuhnya. Walau bagaimanapun, mencegah kehilangan kemas kini tidak boleh diselesaikan oleh pengawal urus niaga pangkalan data sahaja. Aplikasi perlu menambah kunci yang diperlukan pada data yang akan dikemas kini.
"Bacaan kotor", "bacaan tidak boleh diulang" dan "baca hantu" sebenarnya adalah masalah ketekalan bacaan pangkalan data, yang mesti diselesaikan oleh pangkalan data yang menyediakan mekanisme pengasingan transaksi tertentu. Cara pangkalan data melaksanakan pengasingan transaksi pada dasarnya boleh dibahagikan kepada dua jenis berikut.
Salah satunya ialah mengunci data sebelum membacanya untuk menghalang transaksi lain daripada mengubah suai data.
Yang lain adalah untuk menjana syot kilat data (Snapshot) yang konsisten bagi titik masa permintaan data melalui mekanisme tertentu tanpa menambah sebarang kunci dan menggunakan syot kilat ini untuk menyediakan tahap ketekalan tertentu (tahap penyata atau tahap transaksi ) Baca. Dari perspektif pengguna, nampaknya pangkalan data boleh menyediakan berbilang versi data yang sama Oleh itu, teknologi ini dipanggil data multi-version concurrency control (pendek kata MVCC atau MCC), yang juga sering dipanggil pangkalan data berbilang versi.
Bacaan konsisten, juga dikenali sebagai bacaan syot kilat. Mekanisme MVCC digunakan untuk membaca data yang diserahkan dalam buat asal. Jadi bacaannya tidak menyekat.
Bacaan konsisten mesti membaca data yang telah diserahkan pada masa tertentu Terdapat kes khas: data yang diubah suai dalam urus niaga ini, malah data yang tidak terikat boleh dibaca di bahagian akhir transaksi ini. tiba. Bacaan konsisten merujuk kepada kenyataan pilih biasa tanpa klausa seperti untuk kemas kini, dalam mod kongsi, dsb. Data yang diserahkan dalam buat asal digunakan, dan tiada kunci diperlukan (kecuali MDL). Bacaan semasa merujuk kepada bacaan yang dilakukan oleh pernyataan seperti kemas kini, padam, pilih untuk kemas kini, pilih dalam mod kongsi, dll. Mereka membaca data terkini dalam pangkalan data dan mengunci baris dan jurang bacaan (jam pengasingan RR). Jika kunci tidak dapat diperoleh, ia akan menunggu sehingga ia diperoleh atau tamat masa.
Semakin ketat pengasingan urus niaga pangkalan data, semakin kecil kesan sampingan serentak, tetapi semakin besar harga yang dibayar, kerana pengasingan urus niaga pada asasnya menjadikan urus niaga "bersiri" pada tahap tertentu, yang jelas tidak konsisten dengan " " Concurrency" ialah oxymoron. Pada masa yang sama, aplikasi yang berbeza mempunyai keperluan yang berbeza untuk konsistensi bacaan dan pengasingan transaksi Contohnya, banyak aplikasi tidak sensitif kepada "bacaan tidak boleh diulang" dan "bacaan hantu" dan mungkin lebih mengambil berat tentang keupayaan untuk mengakses data secara serentak.
Untuk menyelesaikan percanggahan antara "pengasingan" dan "konkurensi", ISO/ANSI SQL92 mentakrifkan 4 tahap pengasingan transaksi Setiap peringkat mempunyai tahap pengasingan yang berbeza dan membenarkan kesan sampingan yang berbeza bahawa percanggahan antara "pengasingan" dan "konkurensi" diseimbangkan dengan memilih tahap pengasingan yang berbeza. Jadual 20-5 menyediakan ringkasan yang baik tentang ciri-ciri empat tahap pengasingan ini.
Setiap pangkalan data tertentu tidak semestinya melaksanakan sepenuhnya empat tahap pengasingan di atas Oracle hanya menyediakan dua tahap pengasingan standard: Baca komited dan Boleh Bersiri, dan juga menyediakan tahap pengasingan Baca sahaja yang ditentukan sendiri menyokong ISO/ANSI SQL92 di atas Sebagai tambahan kepada empat tahap pengasingan yang ditakrifkan, ia juga menyokong tahap pengasingan yang dipanggil "syot kilat", tetapi secara tegasnya ia ialah tahap pengasingan Bersiri yang dilaksanakan menggunakan MVCC.
MySQL menyokong kesemua 4 tahap pengasingan, tetapi dalam pelaksanaan khusus, terdapat beberapa ciri Sebagai contoh, dalam beberapa tahap pengasingan, bacaan konsisten MVCC digunakan, tetapi dalam beberapa kes kandungan ini tidak dibincangkan kemudiannya.
4. Dapatkan perbalahan kunci baris InnoDB
Anda boleh menganalisis perbalahan kunci baris pada sistem dengan menyemak pembolehubah status InnoDB_row_lock.
mysql> tunjukkan status seperti 'innodb_row_lock%';
| Nilai_pembolehubah |
|.>
|. InnoDB_row_lock_time |.| InnoDB_row_lock_time_avg ||5 baris dalam set (0.01 saat)
Jika anda mendapati bahawa perbalahan kunci adalah serius, seperti nilai InnoDB_row_lock_waits dan InnoDB_row_lock_time_avg adalah agak tinggi, anda juga boleh menetapkan Monitor InnoDB kepada amati selanjutnya jadual dan data di mana konflik kunci berlaku Tunggu, dan analisis punca pertikaian kunci.
Kaedah khusus adalah seperti berikut:
mysql> CREATE TABLE innodb_monitor(a INT) ENGINE=INNODB;
Soalan OK, 0 baris terjejas (0.14 saat)
Kemudian anda boleh menggunakan pernyataan berikut untuk melihat:
mysql> Tunjukkan status innodbG;
Monitor boleh berhenti melihat dengan mengeluarkan kenyataan berikut:
mysql> ; DROP TABLE innodb_monitor;
Pertanyaan OK, 0 baris terjejas (0.05 saat)
Selepas menetapkan monitor, dalam kandungan paparan SHOW INNODB STATUS, akan terdapat maklumat terperinci tentang kunci semasa menunggu, termasuk nama Jadual, jenis kunci, status rekod kunci, dsb., untuk memudahkan analisis lanjut dan penentuan masalah. Selepas membuka monitor, kandungan yang dipantau akan direkodkan dalam log setiap 15 saat secara lalai Jika ia dibuka untuk masa yang lama, fail .err akan menjadi sangat besar, selepas mengesahkan punca masalah, pengguna mesti ingat untuk memadamkan jadual pemantauan untuk menutup monitor, atau dengan memulakan pelayan menggunakan pilihan "--console" untuk mematikan penulisan fail log.
5. Mod kunci baris InnoDB dan kaedah penguncian
InnoDB melaksanakan dua jenis kunci baris berikut.
Kunci kongsi (S): membenarkan satu transaksi membaca baris dan menghalang transaksi lain daripada mendapatkan kunci eksklusif pada set data yang sama.
Kunci eksklusif (X): Membenarkan transaksi yang memperoleh kunci eksklusif untuk mengemas kini data dan menghalang transaksi lain daripada mendapatkan kunci baca kongsi dan kunci tulis eksklusif pada set data yang sama.
Selain itu, untuk membolehkan kunci baris dan kunci meja wujud bersama dan melaksanakan mekanisme penguncian berbutir-butir, InnoDB juga mempunyai dua kunci niat yang digunakan secara dalaman (Kunci Niat). kunci adalah Ia adalah kunci meja.
Kunci kongsi niat (IS): Urus niaga berhasrat untuk menambah kunci kongsi baris pada baris data Urus niaga mesti mendapatkan kunci IS jadual terlebih dahulu sebelum menambah kunci kongsi pada baris data.
Kunci eksklusif niat (IX): Urus niaga bercadang untuk menambah kunci eksklusif baris pada baris data Urus niaga mesti mendapatkan kunci IX jadual terlebih dahulu sebelum menambah kunci eksklusif pada baris data.
Kunci niat ditambah secara automatik oleh InnoDB dan tidak memerlukan campur tangan pengguna.
Ringkasannya adalah seperti berikut:
1 Untuk penyataan KEMASKINI, PADAM dan INSERT, InnoDB akan secara automatik menambah kunci eksklusif (X) pada set data yang terlibat
2 . Untuk penyataan SELECT biasa, InnoDB tidak akan menambah sebarang kunci
3. Transaksi boleh menambah kunci kongsi atau kunci eksklusif pada rekod yang ditetapkan.
Kunci kongsi: PILIH * DARI nama_jadual DI MANA ... KUNCI DALAM MOD KONGSI.
Kunci eksklusif (X): PILIH * DARI nama_jadual DI MANA ... UNTUK KEMASKINI.
Gunakan PILIH ... DALAM MOD KONGSI Ia digunakan terutamanya untuk mengesahkan sama ada barisan rekod tertentu wujud apabila kebergantungan data diperlukan dan untuk memastikan tiada sesiapa yang melakukan operasi KEMASKINI atau PADAM. dalam rekod ini.
Namun, jika transaksi semasa juga perlu mengemas kini rekod, ia berkemungkinan akan menyebabkan kebuntuan Bagi aplikasi yang perlu mengemas kini rekod baris selepas menguncinya, anda harus menggunakan PILIH... UNTUK KEMASKINI kaedah untuk mendapatkan Kunci eksklusif.
6. Pelaksanaan kunci baris InnoDB
Kunci baris InnoDB dilaksanakan dengan mengunci item indeks pada indeks Ini berbeza daripada MySQL dan Oracle, yang dilaksanakan dengan mengunci item indeks dalam blok data Ini dicapai dengan mengunci baris data yang sepadan.
Ciri pelaksanaan kunci baris InnoDB bermakna InnoDB menggunakan kunci peringkat baris hanya apabila data diambil melalui keadaan indeks Jika tidak, InnoDB akan menggunakan kunci jadual!
Dalam aplikasi praktikal, perhatian khusus harus diberikan kepada ciri kunci baris InnoDB ini, jika tidak, ia boleh menyebabkan sejumlah besar konflik kunci, sekali gus menjejaskan prestasi serentak.
(1) Apabila membuat pertanyaan tanpa syarat indeks, InnoDB menggunakan kunci meja dan bukannya kunci baris.
(2) Memandangkan kunci baris MySQL adalah untuk indeks, bukan untuk rekod, walaupun rekod baris yang berbeza diakses,
tetapi jika indeks yang sama digunakan kunci, akan ada konflik kunci. Sila beri perhatian kepada perkara ini semasa mereka bentuk aplikasi anda.
(3) Apabila jadual mempunyai berbilang indeks, transaksi yang berbeza boleh menggunakan indeks yang berbeza untuk mengunci baris yang berbeza
Selain itu, sama ada menggunakan indeks kunci utama, indeks unik atau indeks biasa, InnoDB akan. gunakan kunci baris untuk mengunci data.
(4) Walaupun medan indeks digunakan dalam keadaan, sama ada untuk menggunakan indeks untuk mendapatkan data ditentukan oleh MySQL dengan menilai kos pelan pelaksanaan yang berbeza Jika MySQL percaya bahawa imbasan jadual penuh adalah lebih cekap, seperti Untuk beberapa jadual yang sangat kecil, ia tidak akan menggunakan indeks Dalam kes ini, InnoDB akan menggunakan kunci meja dan bukannya kunci baris. Oleh itu, apabila menganalisis konflik kunci, jangan lupa untuk menyemak pelan pelaksanaan SQL untuk mengesahkan sama ada indeks itu benar-benar digunakan. Untuk perbincangan terperinci tentang keadaan di mana MySQL tidak menggunakan indeks, lihat pengenalan kepada bahagian "Isu Indeks" dalam bab ini.
7. Kunci celah (Kunci Kekunci Seterusnya)
Apabila kami mendapatkan data menggunakan syarat julat dan bukannya syarat kesaksamaan dan meminta kunci dikongsi atau eksklusif, InnoDB akan mengunci entri indeks rekod data sedia ada yang memenuhi syarat untuk nilai utama yang berada dalam julat syarat tetapi tidak wujud Rekod itu dipanggil "GAP", dan InnoDB juga akan mengunci "jurang" ini. Mekanisme penguncian ini ialah apa yang dipanggil kunci jurang (Kunci Kekunci Seterusnya). Jika terdapat hanya 101 rekod dalam jadual emp, nilai empid ialah 1,2,...,100,101 SQL berikut:
Pilih * daripada emp di mana empid > 🎜>
ialah pengambilan keadaan julat InnoDB bukan sahaja akan mengunci rekod dengan nilai empid 101 yang memenuhi syarat, tetapi juga mengunci "jurang" dengan nilai empid lebih daripada 101 (rekod ini tidak wujud) . Tujuan InnoDB menggunakan kunci jurang adalah, di satu pihak, untuk menghalang bacaan hantu dan memenuhi keperluan tahap pengasingan yang berkaitan Untuk contoh di atas, jika kunci jurang tidak digunakan, jika transaksi lain memasukkan sebarang rekod dengan emid lebih daripada 100. , maka jika transaksi ini Jika pernyataan di atas dilaksanakan semula, bacaan hantu akan berlaku sebaliknya, ia adalah untuk memenuhi keperluan pemulihan dan replikasinya. Kesan pemulihan dan replikasinya pada mekanisme kunci, serta penggunaan kunci jurang oleh InnoDB di bawah tahap pengasingan yang berbeza, akan diperkenalkan lagi dalam bab seterusnya. Jelas sekali, apabila menggunakan keadaan julat untuk mendapatkan dan mengunci rekod, mekanisme penguncian InnoDB akan menyekat pemasukan nilai kunci serentak dalam julat yang layak, yang sering mengakibatkan penantian kunci yang serius. Oleh itu, dalam pembangunan aplikasi sebenar, terutamanya aplikasi dengan banyak sisipan serentak, kita mesti cuba mengoptimumkan logik perniagaan, cuba menggunakan syarat yang sama untuk mengakses data kemas kini, dan mengelak daripada menggunakan keadaan julat. Nota istimewa ialah InnoDB, selain menggunakan kunci celah semasa mengunci melalui keadaan julat, juga akan menggunakan kunci celah jika keadaan yang sama digunakan untuk meminta kunci bagi rekod yang tidak wujud! Keperluan untuk pemulihan dan replikasi, kesan pada mekanisme kunci InnoDBMySQL merekodkan kejayaan pelaksanaan INSERT, UPDATE, DELETE dan pernyataan SQL lain untuk mengemas kini data melalui BINLOG, dan dengan itu merealisasikan pangkalan data MySQL Pemulihan dan replikasi tuan-hamba. Mekanisme pemulihan MySQL (replikasi sebenarnya adalah pemulihan berasaskan BINLOG berterusan pada Slave Mysql) mempunyai ciri-ciri berikut. Pertama, pemulihan MySQL berada pada tahap pernyataan SQL, iaitu, melaksanakan semula pernyataan SQL dalam BINLOG. Ini berbeza daripada pangkalan data Oracle, yang berdasarkan blok fail pangkalan data. Kedua, BINLOG MySQL direkodkan mengikut susunan transaksi diserahkan, dan pemulihan juga dilakukan dalam susunan ini. Ini juga berbeza daripada Oracle memulihkan data mengikut Nombor Perubahan Sistem (SCN) Apabila setiap urus niaga bermula, Oracle akan memperuntukkan SCN yang unik secara global dan urutan masa permulaan transaksi adalah Konsisten. Daripada dua perkara di atas, kita boleh tahu bahawa mekanisme pemulihan MySQL memerlukan sebelum transaksi diserahkan, transaksi serentak lain tidak boleh memasukkan sebarang rekod yang memenuhi syarat kuncinya, iaitu, bacaan hantu tidak dibenarkan telah melebihi Keperluan tahap pengasingan "boleh dibaca berulang" ISO/ANSI SQL92 sebenarnya memerlukan urus niaga bersiri. Selain itu, untuk pernyataan SQL seperti "masukkan ke dalam tab_target pilih * dari tab_sumber di mana ..." dan "buat jadual tab_baru ...pilih ... Dari tab_sumber di mana ...(CTAS)", pengguna Tiada operasi kemas kini pada source_tab, tetapi MySQL melakukan pemprosesan khas untuk pernyataan SQL jenis ini. (Di sini InnoDB menambah kunci kongsi pada tab_sumber dan tidak menggunakan teknologi pembacaan konsistensi data berbilang versi!)
Seperti yang dapat dilihat daripada di atas, selepas menetapkan nilai pembolehubah sistem innodb_locks_unsafe_for_binlog kepada "hidup", InnoDB tidak lagi mengunci tab_sumber, dan hasilnya adalah selaras dengan logik aplikasi, tetapi jika anda menganalisis kandungan BINLOG:
SET TIMESTAMP=1169175130 ;
BERMULA;
# di 274
#070119 10:51:57 pelayan id Query 1 end_log_log =1 exec_time=0 error_code=0
SET TIMESTAMP=1169175117;
kemas kini source_tab set name = '8' where name = '1';
# at 379
#070119 10:52:10 id pelayan 1 end_log_pos 406 error_code=0
SET TIMESTAMP=1169175134;
BERMULA;
#070119 10:51:29 id pelayan 1 end_log_pos 119 Thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1169175089;
sisipkan d1, nama_tab dari tab_sumber di mana nama = '1';
# di 593
#070119 10:52:14 id pelayan 1 end_log_pos 620 Xid = 7
KOMIT;
Boleh didapati bahawa dalam BINLOG, lokasi operasi kemas kini adalah INSERT ..Sebelum PILIH, jika anda menggunakan BINLOG ini untuk pemulihan pangkalan data, hasil pemulihan tidak akan sepadan dengan logik aplikasi yang sebenar jika anda menyalin akan membawa kepada ketidakkonsistenan antara pangkalan data tuan dan hamba!
Oleh itu, pernyataan INSERT...SELECT... dan CREATE TABLE...SELECT... mungkin menghalang kemas kini serentak pada jadual sumber, menyebabkan menunggu untuk kunci jadual sumber. Jika pertanyaan itu rumit, ia akan menyebabkan masalah prestasi yang serius, dan kami harus cuba mengelak daripada menggunakannya dalam aplikasi kami. Malah, MySQL memanggil SQL bukan deterministik SQL jenis ini dan tidak disyorkan.
Jika SQL jenis ini mesti digunakan untuk melaksanakan logik perniagaan dalam aplikasi, dan anda tidak mahu menjejaskan kemas kini serentak jadual sumber, anda boleh mengambil dua langkah berikut:
Pertama, ambil contoh di atas Seperti dalam kaedah, tetapkan nilai innodb_locks_unsafe_for_binlog kepada "on" untuk memaksa MySQL menggunakan bacaan konsisten data berbilang versi. Tetapi harga yang dibayar ialah data mungkin tidak dapat dipulihkan atau disalin dengan betul menggunakan binlog, jadi kaedah ini tidak disyorkan.
Yang kedua ialah mencapainya secara tidak langsung dengan menggunakan kombinasi "pilih * dari tab_sumber ... Ke dalam fail" dan "memuat data dalam fail ..." Dengan cara ini, MySQL tidak akan mengunci tab_sumber.
8. Perbezaan dalam pembacaan konsisten InnoDB dan penguncian di bawah tahap pengasingan yang berbeza
Seperti yang dinyatakan sebelum ini, kunci dan data berbilang versi adalah kunci kepada pelaksanaan bacaan konsisten dan pengasingan ISO/ANSI SQL92 InnoDB tahap Oleh itu, di bawah tahap pengasingan yang berbeza, strategi bacaan yang konsisten dan kunci yang diperlukan yang digunakan oleh InnoDB semasa memproses SQL adalah berbeza. Pada masa yang sama, ciri-ciri pemulihan data dan mekanisme replikasi juga mempunyai impak yang besar pada beberapa strategi bacaan konsisten SQL dan strategi kunci. Ciri-ciri ini diringkaskan seperti yang ditunjukkan dalam Jadual 20-16 untuk kemudahan pembaca.
1: Apabila tahap pengasingan ialah RC, kunci jurang tidak digunakan Dokumentasi rasmi menerangkan seperti berikut:
Setiap bacaan yang konsisten, walaupun dalam transaksi yang sama, menetapkan dan membacanya sendiri. petikan. Untuk maklumat tentang bacaan yang konsisten, lihat Bahagian 14.8.2.3, “Bacaan Tidak Mengunci Konsisten”.
Untuk mengunci bacaan (PILIH dengan MOD UNTUK KEMASKINI atau LOCK IN SHARE), kenyataan KEMASKINI dan PADAM, kunci InnoDB hanya rekod indeks, bukan jurang sebelum mereka, dan dengan itu membenarkan kemasukan percuma rekod baharu di sebelah rekod terkunci Pengunci jurang hanya digunakan untuk semakan kekangan kunci asing dan semakan kunci pendua.
Dokumen Rasmi. alamat perihalan ialah: https://dev.mysql.com/doc/refman/5.5/en/innodb-transaction-isolation-levels.html
2: Di bawah tahap pengasingan bacaan boleh berulang, jika indeks adalah Unik, dan carian juga unik, tiada kunci celah diperlukan, jika tidak, kunci celah akan digunakan Penerangan rasmi adalah seperti berikut:
BACA DIULANG
Ini ialah tahap pengasingan lalai untuk. Bacaan konsisten dalam urus niaga yang sama membaca petikan yang ditetapkan oleh bacaan pertama Ini bermakna jika anda mengeluarkan beberapa kenyataan SELECT biasa (tidak mengunci) dalam transaksi yang sama, penyataan SELECT ini juga konsisten antara satu sama lain. . , atau keadaan carian jenis julat.
Untuk indeks unik dengan keadaan carian unik, InnoDB hanya mengunci rekod indeks yang ditemui, bukan jurang sebelum itu.
Untuk keadaan carian lain, InnoDB mengunci julat indeks yang diimbas, menggunakan kunci celah atau kunci kekunci seterusnya untuk menyekat sisipan oleh sesi lain ke dalam jurang yang diliputi oleh julat Untuk mendapatkan maklumat tentang kunci celah dan kunci kekunci seterusnya, lihat Bahagian 14.8.1, "Penguncian InnoDB". .
Alamat dokumentasi rasmi ialah: https://dev.mysql.com/doc/refman/5.5/en/innodb-transaction-isolation-levels.html
9.
Untuk jadual InnoDB, kunci peringkat baris harus digunakan dalam kebanyakan kes, kerana transaksi dan kunci baris selalunya menjadi sebab mengapa kami memilih jadual InnoDB. Walau bagaimanapun, dalam urus niaga khas individu, kunci peringkat meja juga boleh dipertimbangkan.
Situasi pertama ialah: urus niaga perlu mengemas kini kebanyakan atau semua data, dan jadual adalah agak besar Jika kunci baris lalai digunakan, bukan sahaja kecekapan pelaksanaan transaksi akan menjadi rendah, tetapi ia juga boleh menyebabkan urus niaga lain menunggu kunci lama dan konflik Kunci, dalam kes ini, anda boleh mempertimbangkan untuk menggunakan kunci meja untuk meningkatkan kelajuan pelaksanaan transaksi.
Situasi kedua ialah: urus niaga melibatkan berbilang jadual dan agak kompleks, yang berkemungkinan menyebabkan kebuntuan dan menyebabkan sejumlah besar penarikan balik transaksi. Dalam kes ini, anda juga boleh mempertimbangkan untuk mengunci jadual yang terlibat dalam transaksi sekali untuk mengelakkan kebuntuan dan mengurangkan overhed pangkalan data yang disebabkan oleh rollback transaksi.
Sudah tentu, kedua-dua jenis transaksi ini tidak sepatutnya terlalu banyak dalam aplikasi, jika tidak, anda harus mempertimbangkan untuk menggunakan jadual MyISAM.
Di bawah InnoDB, anda harus memberi perhatian kepada dua perkara berikut apabila menggunakan kunci meja.
(1) Walaupun anda boleh menambah kunci peringkat jadual pada InnoDB menggunakan LOCK TABLES, perlu diingatkan bahawa kunci jadual tidak diuruskan oleh lapisan enjin storan InnoDB, tetapi oleh lapisan atas: MySQL Server , hanya apabila autocommit=0, innodb_table_locks=1 (tetapan lalai), lapisan InnoDB boleh mengetahui kunci jadual yang ditambahkan oleh MySQL, dan Pelayan MySQL juga boleh melihat kunci baris yang ditambahkan oleh InnoDB Dalam kes ini, InnoDB boleh mengenal pasti jadual secara automatik. kunci tahap yang terlibat, jika tidak, InnoDB tidak akan dapat mengesan dan mengendalikan kebuntuan tersebut secara automatik. Mengenai kebuntuan, kita akan terus membincangkannya di bahagian seterusnya.
(2) Apabila menggunakan LOCK TABLES untuk mengunci jadual InnoDB, berhati-hati untuk menetapkan AUTOCOMMIT kepada 0, jika tidak MySQL tidak akan mengunci jadual; jangan gunakan UNLOCK TABLES untuk melepaskan kunci jadual sebelum transaksi berakhir. Oleh kerana UNLOCK TABLES secara tersirat akan melakukan transaksi; COMMIT atau ROLLBACK tidak boleh melepaskan kunci peringkat jadual yang ditambahkan dengan LOCK TABLES dan kunci meja mesti dilepaskan dengan UNLOCK TABLES. Untuk kaedah yang betul, lihat pernyataan berikut.
KUNCI JADUAL t1 TULIS, t2 BACA, ...;
[buat sesuatu dengan jadual t1 dan t2 di sini];
KOMIT;
BUKA KUNCI JADUAL;
10. Mengenai kebuntuan
Seperti yang dinyatakan di atas, kunci meja MyISAM adalah bebas kebuntuan Ini kerana MyISAM sentiasa memperoleh semua kunci yang diperlukan sekali gus, sama ada untuk memenuhi kesemuanya atau sebaliknya tunggu, supaya tidak ada jalan buntu. Tetapi dalam InnoDB, kecuali untuk transaksi yang terdiri daripada satu SQL, kunci diperoleh secara beransur-ansur, yang menentukan bahawa kebuntuan mungkin berlaku dalam InnoDB. Jadual 20-17 menunjukkan contoh kebuntuan.
Dalam contoh di atas, kedua-dua urus niaga perlu mendapatkan kunci eksklusif yang dipegang oleh pihak yang satu lagi untuk meneruskan urus niaga menunggu kunci kitaran ini adalah jalan buntu yang biasa.
Selepas kebuntuan berlaku, InnoDB biasanya boleh mengesannya secara automatik dan menyebabkan satu transaksi melepaskan kunci dan melancarkan semula, manakala transaksi lain memperoleh kunci dan terus menyelesaikan transaksi. Walau bagaimanapun, apabila kunci luaran atau kunci meja terlibat, InnoDB tidak dapat mengesan kebuntuan sepenuhnya secara automatik Ini perlu diselesaikan dengan menetapkan parameter tamat masa tunggu kunci innodb_lock_wait_timeout. Perlu diingatkan bahawa parameter ini bukan sahaja digunakan untuk menyelesaikan masalah kebuntuan Apabila akses serentak agak tinggi, jika sejumlah besar transaksi digantung kerana kunci yang diperlukan tidak dapat diperoleh dengan segera, ia akan menduduki sejumlah besar sumber komputer. dan menyebabkan masalah prestasi yang serius Masalahnya malah menyeret merentasi pangkalan data. Kita boleh mengelakkan situasi ini dengan menetapkan ambang tamat masa menunggu kunci yang sesuai.
Secara umumnya, kebuntuan ialah masalah reka bentuk aplikasi Dengan melaraskan proses perniagaan, reka bentuk objek pangkalan data, saiz transaksi dan pernyataan SQL yang mengakses pangkalan data, kebanyakan kebuntuan boleh dielakkan.
Berikut akan memperkenalkan beberapa kaedah biasa untuk mengelakkan kebuntuan melalui contoh.
(1) Dalam aplikasi, jika program yang berbeza mengakses berbilang jadual secara serentak, cuba bersetuju untuk mengakses jadual dalam susunan yang sama, yang boleh mengurangkan peluang kebuntuan dengan banyak. Dalam contoh berikut, kerana kedua-dua sesi mengakses dua jadual dalam susunan yang berbeza, kemungkinan kebuntuan adalah sangat tinggi! Tetapi jika akses dilakukan dalam susunan yang sama, kebuntuan boleh dielakkan.
(2) Apabila program memproses data dalam kelompok, jika data diisih terlebih dahulu untuk memastikan setiap utas memproses rekod dalam susunan tetap, ia juga boleh menjadi sangat dikurangkan.
(4) Seperti yang dinyatakan sebelum ini, di bawah tahap pengasingan REPEATABLE-READ, jika dua utas menggunakan PILIH...UNTUK KEMASKINI untuk menambah kunci eksklusif pada rekod dengan keadaan yang sama pada masa yang sama, jika tiada rekod yang memenuhi syarat, kedua-dua benang akan Semua akan berjaya dikunci. Program ini mendapati bahawa rekod itu belum wujud dan cuba memasukkan rekod baharu Jika kedua-dua utas melakukan ini, kebuntuan akan berlaku. Dalam kes ini, menukar tahap pengasingan kepada READ COMMITTED boleh mengelakkan masalah.
(5) Apabila tahap pengasingan DIBACA KOMITED, jika kedua-dua utas melaksanakan PILIH...UNTUK KEMASKINI dahulu, tentukan sama ada terdapat rekod yang memenuhi syarat Jika tidak , , masukkan rekod. Pada masa ini, hanya satu utas yang boleh dimasukkan dengan jayanya, dan utas lain akan menunggu kunci Apabila utas pertama diserahkan, utas kedua akan membuat ralat disebabkan oleh kunci utama Walau bagaimanapun, walaupun utas ini membuat ralat akan memperoleh kunci eksklusif! Pada masa ini, jika urutan ketiga digunakan untuk kunci eksklusif, kebuntuan juga akan berlaku.
Dalam kes ini, anda boleh terus melakukan operasi sisipan dan kemudian menangkap pengecualian pendua kunci utama, atau sentiasa laksanakan ROLLBACK untuk melepaskan kunci eksklusif yang diperoleh apabila menghadapi ralat pendua kunci utama.
Walaupun kebuntuan boleh dikurangkan dengan banyak melalui reka bentuk dan pengoptimuman SQL serta langkah lain yang diperkenalkan di atas, kebuntuan sukar dielakkan sepenuhnya. Oleh itu, adalah kebiasaan pengaturcaraan yang baik untuk sentiasa menangkap dan mengendalikan pengecualian kebuntuan dalam pengaturcaraan.
Jika kebuntuan berlaku, anda boleh menggunakan arahan SHOW INNODB STATUS untuk menentukan punca kebuntuan terakhir. Keputusan yang dikembalikan termasuk maklumat terperinci tentang urus niaga yang berkaitan dengan kebuntuan, seperti pernyataan SQL yang menyebabkan kebuntuan, kunci yang diperoleh urus niaga, kunci apa yang sedang menunggu dan urus niaga yang ditarik balik. Berdasarkan ini, punca kebuntuan dan langkah penambahbaikan boleh dianalisis.
Berikut ialah contoh output SHOW INNODB STATUS:
mysql> show innodb status G
InnoDB Summary
Bab ini memfokuskan pada MyISAM dalam MySQL Ciri-ciri pelaksanaan kunci peringkat jadual dan kunci peringkat baris InnoDB dibincangkan, dan masalah kunci serta penyelesaian yang sering dihadapi oleh kedua-dua enjin storan dibincangkan.
Untuk kunci jadual MyISAM, perkara berikut dibincangkan terutamanya:
(1) Kunci baca kongsi (S) serasi, tetapi kunci baca kongsi (S) tidak serasi dengan tulisan eksklusif kunci (X) dan kunci tulis eksklusif (X) adalah saling eksklusif, yang bermaksud bahawa membaca dan menulis adalah bersiri.
(2) Dalam keadaan tertentu, MyISAM membenarkan pertanyaan dan sisipan dilaksanakan secara serentak Kami boleh menggunakan ini untuk menyelesaikan masalah pertikaian kunci untuk pertanyaan dan sisipan ke dalam jadual yang sama dalam aplikasi.
(3) Mekanisme penjadualan kunci lalai MyISAM ialah keutamaan tulis, yang tidak semestinya sesuai untuk semua aplikasi Pengguna boleh melaraskan membaca dan menulis dengan menetapkan parameter LOW_PRIORITY_UPDATES atau menentukan pilihan LOW_PRIORITY dalam INSERT, UPDATE dan. PADAM kenyataan.
(4) Disebabkan butiran penguncian kunci meja yang besar dan siri antara membaca dan menulis, jika terdapat banyak operasi kemas kini, jadual MyISAM mungkin mempunyai kunci menunggu yang serius. Anda boleh mempertimbangkan untuk menggunakan jadual InnoDB mengurangkan konflik kunci.
Untuk jadual InnoDB, bab ini membincangkan kandungan berikut terutamanya.
Kunci baris InnoDB adalah berdasarkan indeks kunci Jika data tidak diakses melalui indeks, InnoDB akan menggunakan kunci meja.
Memperkenalkan mekanisme kunci jurang InnoDB (Kunci seterusnya) dan sebab InnoDB menggunakan kunci jurang.
Di bawah tahap pengasingan yang berbeza, mekanisme penguncian InnoDB dan strategi bacaan yang konsisten adalah berbeza.
Pemulihan dan replikasi MySQL juga mempunyai impak yang besar pada mekanisme kunci InnoDB dan strategi bacaan yang konsisten.
Konflik kunci dan juga kebuntuan sukar dielakkan sepenuhnya.
Selepas memahami ciri kunci InnoDB, pengguna boleh mengurangkan konflik kunci dan kebuntuan melalui reka bentuk dan pelarasan SQL, termasuk:
Gunakan tahap pengasingan yang lebih rendah sebanyak mungkin
Reka bentuk indeks dengan teliti dan cuba gunakan indeks untuk mengakses data untuk menjadikan penguncian lebih tepat, sekali gus mengurangkan kemungkinan konflik kunci.
Pilih saiz urus niaga yang munasabah dan urus niaga kecil akan mempunyai lebih sedikit peluang konflik kunci.
Apabila paparan mengunci set rekod, sebaiknya minta tahap kunci yang mencukupi pada satu masa. Sebagai contoh, jika anda ingin mengubah suai data, sebaiknya gunakan kunci eksklusif secara langsung dan bukannya memohon kunci kongsi dahulu dan kemudian minta kunci eksklusif apabila mengubah suai, yang boleh membawa kepada jalan buntu dengan mudah.
Apabila program berbeza mengakses sekumpulan jadual, mereka harus cuba bersetuju untuk mengakses setiap jadual dalam susunan yang sama Untuk jadual, cuba akses baris dalam jadual dalam susunan tetap. Ini sangat mengurangkan peluang kebuntuan.
Cuba gunakan keadaan kesamarataan untuk mengakses data, bagi mengelakkan kesan kunci jurang pada sisipan serentak.
Jangan memohon tahap kunci yang melebihi keperluan sebenar melainkan perlu, jangan paparkan penguncian semasa membuat pertanyaan.
Untuk beberapa transaksi tertentu, kunci meja boleh digunakan untuk meningkatkan kelajuan pemprosesan atau mengurangkan kemungkinan kebuntuan.
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
