Membawa anda memahami kumpulan penimbal pangkalan data (Kolam Penampan) dalam MySQL

Untuk jadual yang menggunakan enjin storan InnoDB, ruang storan diuruskan dalam unit halaman sebagai butiran asas untuk menukar masuk dan keluar antara memori dan cakera. Apabila kita memuatkan halaman dari cakera ke dalam memori, cakera I/O akan dilakukan. Overhed cakera I/O sangat mempengaruhi prestasi keseluruhan Jika kita membaca halaman yang sepadan secara langsung dari memori, bukankah ia akan mengurangkan kehilangan prestasi yang disebabkan oleh cakera I/O dan kecekapan akan bertambah baik. Berdasarkan ini, Kolam Penampan (Buffer Pool) muncul, jadi seterusnya, mari kita bincangkan tentang Kolam Penampan dalam InnoDB.

Kolam Penampan

Sesetengah orang mungkin berpendapat bahawa memandangkan kumpulan penimbal sangat bagus, mengapa tidak simpan sahaja semua data dalam kumpulan penimbal Tidak, tidak, tidak , Kolam penimbal ialah memori bersebelahan yang diperuntukkan oleh sistem pengendalian. Memori mempunyai kapasiti yang jauh lebih kecil daripada cakera dan mahal. Jadi berapa banyak memori yang akan diperuntukkan oleh sistem pengendalian kepada kumpulan penimbal?

• Secara lalai, saiz kumpulan penimbal ialah 128MB

Sudah tentu, jika mesin anda mempunyai kapasiti memori yang sangat besar, anda boleh mengkonfigurasi parameter pilihan permulaan; dalam fail konfigurasi innodb_buffer_pool_sizeUnit ialah bait, dan minimum tidak boleh kurang daripada 5MB.

Struktur dalaman kumpulan penimbal

Kolam penimbal membahagikan memori berterusan yang diperuntukkan oleh sistem pengendalian kepada beberapa halaman (halaman penimbal) dengan saiz lalai 16KB [Pada masa ini, terdapat is no actual Halaman cakera dicache dalam Buffer Pool]. Apabila kita menukar halaman dari cakera ke dalam buffer pool, bagaimana kita memperuntukkan lokasi? Oleh itu, beberapa maklumat kawalan diperlukan untuk mengenal pasti halaman penimbal dalam kumpulan penimbal ini Maklumat kawalan ini disimpan dalam kawasan memori yang dipanggil blok kawalan dan sepadan dengan halaman penimbal satu-satu. Saiz blok kawalan juga ditetapkan. Oleh itu, dalam ruang ingatan yang berterusan ini, pemecahan memori pasti akan berlaku. Secara ringkasnya, struktur dalaman kumpulan penimbal adalah seperti berikut:

• Halaman penimbal
• Blok kawalan: nombor halaman, alamat halaman penimbal dalam kumpulan penimbal, nod senarai terpaut maklumat, dsb.
• Pemecahan memori [Jika memori diperuntukkan dengan betul, pemecahan memori boleh diketepikan]

Pengurusan kolam penimbal

Di atas yang dipautkan maklumat nod senarai disebut dalam blok kawalan, jadi untuk apa nod senarai terpaut digunakan? Ia adalah untuk mengurus halaman dalam kumpulan penimbal dengan lebih baik. Senarai terpaut digunakan untuk memautkan blok kawalan, kerana terdapat surat-menyurat satu dengan satu antara blok kawalan dan halaman penimbal.

1) Senarai terpaut percuma

Memautkan blok kawalan yang sepadan dengan semua halaman penimbal percuma untuk membentuk senarai terpaut.

Masalah diselesaikan: Menukar halaman daripada cakera ke dalam kumpulan penimbal, bagaimana untuk membezakan halaman mana dalam kumpulan penimbal yang percuma? Dengan senarai pautan percuma, apabila halaman cakera ditukar ke dalam kumpulan penimbal, halaman penimbal percuma diperoleh terus daripada senarai pautan percuma, dan maklumat yang sepadan dalam halaman cakera diisi ke dalam blok kawalan yang sepadan dengan halaman penimbal, dan kemudian Hanya padamkan blok kawalan daripada senarai terpaut percuma.

2) Kemas kini senarai terpaut

Jika data halaman penimbal dalam kumpulan penimbal diubah suai, menyebabkan ia tidak konsisten dengan data pada cakera, halaman itu dipanggil kotor muka surat. Pautkan blok kawalan yang sepadan dengan semua halaman kotor untuk membentuk senarai terpaut kemas kini dan muat semula data halaman cache yang sepadan ke cakera pada masa tertentu pada masa hadapan berdasarkan senarai terpaut ini.

3) Senarai terpaut LRU

Saiz kumpulan penimbal adalah terhad Jika halaman cache melebihi saiz kumpulan penimbal, iaitu, tiada halaman penimbal percuma ialah halaman baharu yang akan ditambah Apabila memasuki kumpulan penimbal, strategi LRU digunakan untuk mengalih keluar halaman penimbal lama daripada kumpulan penimbal, dan kemudian menambah halaman baharu. Memandangkan senarai terpaut LRU melibatkan banyak kandungan, kami akan memperkenalkannya secara berasingan seterusnya.

"Falsafah" yang terkandung dalam senarai terpaut LRU

Biar saya nyatakan dahulu mekanisme prabacaan

Mekanisme pengoptimuman pada I/O, prabacaan, sebagai namanya, akan secara tidak segerak Halaman dimuatkan ke dalam kumpulan penimbal yang dijangka diperlukan tidak lama lagi, permintaan ini membawa masuk semua halaman dalam julat, dipanggil 局部性原理, untuk mengurangkan I/O cakera.

Sebelum memahami mekanisme baca ke hadapan, mari semak unit storan logik InnoDB: ruang meja → segmen → takat → halaman. Kawasan dinyatakan secara khusus, yang akan digunakan kemudian: kawasan adalah berterusan 64个页 dalam lokasi fizikal, iaitu saiz kawasan ialah 1MB

The mekanisme pra-bacaan boleh Ia dibahagikan kepada dua jenis berikut:

• Baca ke hadapan linear : Teknik yang meramalkan halaman mana yang mungkin diperlukan tidak lama lagi berdasarkan halaman yang diakses secara berurutan dalam kumpulan penimbal. Dengan mengkonfigurasi parameter innodb_read_ahead_threshold, jika halaman kawasan tertentu yang diakses secara berurutan melebihi nilai parameter ini, permintaan baca tak segerak akan dicetuskan untuk membaca semua halaman di kawasan seterusnya ke dalam kumpulan penimbal.
• Baca ke hadapan secara rawak : Boleh meramalkan bila halaman mungkin diperlukan berdasarkan halaman yang sudah ada dalam kumpulan penimbal, tanpa mengira susunan halaman tersebut dibaca. Jika 13 halaman berturut-turut pada tahap yang sama ditemui dalam kumpulan penimbal, InnoDB akan mengeluarkan permintaan secara tidak segerak untuk mengambil halaman yang selebihnya bagi tahap tersebut. Bacaan rawak dikawal dengan mengkonfigurasi pembolehubah innodb_random_read_ahead.

Bagaimanakah LRU tradisional mengurus halaman penimbal?

Gunakan algoritma LRU untuk mengurus halaman penimbal yang paling kurang digunakan baru-baru ini dan membentuk senarai terpaut yang sepadan untuk penyingkiran mudah.

Apabila halaman diakses [iaitu diakses baru-baru ini]

• Halaman itu berada dalam kumpulan penimbal, alihkan blok kawalan yang sepadan ke kepala senarai LRU
• Halaman itu tiada dalam kumpulan penimbal Dalam kumpulan penimbal, halaman yang paling kurang digunakan baru-baru ini pada penghujung dihapuskan, halaman dimuatkan daripada cakera dan diletakkan di kepala senarai terpaut LRU

Jadi mengapa InnoDB tidak menggunakan algoritma LRU yang intuitif? Sebabnya adalah seperti berikut:

1. Kegagalan baca ke hadapan

   Halaman yang dibaca ke hadapan dalam kolam penimbal akan diletakkan di kepala senarai terpaut LRU, tetapi kebanyakannya Halaman mungkin tidak dibaca.

2. Pencemaran kolam penampan

   Memuatkan banyak halaman yang kurang kerap digunakan ke dalam kumpulan penimbal akan mengalih keluar halaman yang lebih kerap digunakan daripada penimbal Dihapuskan daripada kolam . Contohnya, imbasan jadual penuh

Bagaimanakah LRU yang dioptimumkan mengurus halaman penimbal?

Berdasarkan kelemahan di atas, kaedah khusus yang dioptimumkan membahagikan senarai terpaut LRU tradisional kepada dua bahagian: kawasan data panas [kawasan muda] & kawasan data sejuk [kawasan lama]

• Kawasan data panas [Kawasan muda] : Halaman penimbal yang sangat digunakan
• Kawasan data sejuk [Kawasan lama] : Kawasan kurang digunakan

Rajah struktur yang dipermudahkan adalah seperti berikut:

Seperti yang ditunjukkan dalam rajah, kawasan data panas dan kawasan data sejuk masing-masing menduduki perkadaran yang berbeza, maka kita boleh mengawalnya melalui innodb_old_blocks_pct pilihan permulaanPerkadaran kawasan data sejuk.

Bagaimanakah LRU yang dipertingkatkan boleh menyelesaikan masalah kegagalan baca-depan dengan lebih baik?

• Apabila halaman dimuatkan ke dalam kumpulan penimbal buat kali pertama, blok kawalan di hujung kawasan data sejuk terlebih dahulu dihapuskan (iaitu halaman yang sepadan dihapuskan) , dan kemudian blok kawalan yang sepadan dengan halaman baharu dihapuskan Blok akan diletakkan di kepala kawasan data sejuk terlebih dahulu.
• Jika halaman tidak diakses kemudiannya, ia akan dihapuskan secara perlahan daripada kawasan data sejuk Secara amnya, ia tidak akan menjejaskan halaman penimbal yang kerap diakses dalam kawasan data panas.

Bagaimanakah LRU yang dipertingkatkan boleh menyelesaikan masalah pencemaran kolam penampan dengan lebih baik?

Izinkan saya bercakap tentang kesimpulannya dahulu. Masalah ini tidak dioptimumkan dengan baik. halaman yang dilawati buat kali pertama juga akan diletakkan di kepala kawasan data sejuk, tetapi akses seterusnya akan meletakkannya di kepala kawasan data panas, yang juga akan menyesakkan halaman dengan kekerapan akses yang lebih tinggi.

• Jadi bagaimana untuk menyelesaikan masalah pencemaran kolam penampan?

Kolam penimbal memperkenalkan mekanisme tetingkap masa kawasan data sejuk, iaitu, hanya jika selang masa antara akses seterusnya ke halaman dan akses pertama ke halaman adalah lebih besar daripada nilai tetingkap yang ditentukan, halaman akan dialih keluar dari kawasan data sejuk Pindah ke kepala kawasan data panas. Jika nilai tetingkap kurang daripada nilai yang ditentukan, operasi bergerak tidak akan dilakukan.

Begitu juga, nilai tetingkap boleh ditetapkan melalui parameter
• [unit ms]. Lalai ialah 1000ms, dan 1s akan menapis kebanyakan operasi seperti imbasan jadual penuh. Contohnya, semasa imbasan jadual penuh, selang masa antara berbilang akses ke halaman tidak akan melebihi 1 saat.
• innodb_old_blocks_timeKolam penimbal VS cache pertanyaan

Adakah kumpulan penimbal dan cache pertanyaan adalah perkara yang sama? →Bukan

Kumpulan penimbal akan cuba menyimpan data yang kerap digunakan Apabila MySQL membaca halaman, ia akan terlebih dahulu menentukan sama ada halaman itu berada dalam kumpulan penimbal dibaca secara langsung, jika ia tidak wujud, halaman akan disimpan dalam kumpulan penimbal melalui memori atau cakera dan kemudian dibaca.

Cache pertanyaan menyimpan hasil pertanyaan terlebih dahulu supaya anda boleh mendapatkan hasil secara langsung tanpa melaksanakannya pada masa akan datang. Perlu diingatkan bahawa cache pertanyaan dalam MySQL tidak menyimpan rancangan pertanyaan, tetapi hasil pertanyaan yang sepadan. Syarat hit adalah ketat, dan selagi jadual data berubah, cache pertanyaan akan menjadi tidak sah, jadi kadar hit adalah rendah.
• [Cadangan berkaitan:
tutorial video mysql

]

Atas ialah kandungan terperinci Membawa anda memahami kumpulan penimbal pangkalan data (Kolam Penampan) dalam MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!