Apakah mata pengetahuan tentang membaca kumpulan penimbal halaman dalam MySQL?

Kolam penampan

Kita semua tahu bahawa apabila membaca halaman, anda perlu membaca halaman dari cakera ke memori terlebih dahulu, dan kemudian tunggu CPU memproses data. Proses membaca data dari cakera ke memori adalah sangat perlahan, jadi halaman yang kita baca perlu dicache, jadi MySQL mempunyai kolam penampan ini untuk cache halaman.

Pertama sekali, MySQL akan memohon ruang memori berterusan daripada sistem pengendalian apabila ia dimulakan. Letakkan halaman cache ke dalam kumpulan penimbal dan uruskannya.

mysql> show variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set, 1 warning (0.00 sec)

Kita dapat melihat bahawa lalai ialah 134217728 bait, iaitu 128MB. Jika saiz cache yang kami mohon ialah gandaan 16KB, tidak akan ada masalah pemecahan kerana setiap saiz halaman ialah 16KB.

Komposisi kumpulan penimbal

Setiap halaman mengandungi maklumat blok kawalan yang sepadan, yang disimpan dalam kumpulan penimbal. Setiap blok kawalan menguruskan setiap halaman (kami menggunakan alamat untuk merujuk setiap halaman). MySQL memohon ruang tambahan apabila ia bermula.

Disebabkan ketidakupayaan untuk menggunakan ruang sepenuhnya, akan terdapat beberapa pemecahan yang tidak teratur antara blok kawalan dan halaman cache. Oleh kerana ruang memori yang digunakan oleh MySQL pada sistem pengendalian memerlukan saiz ruang blok kawalan tertentu, dan saiz tertentu tidak dapat ditentukan, tidak dapat dielakkan bahawa akan ada ruang yang tidak boleh digunakan.

senarai terpaut percuma

Senarai terpaut percuma, seperti namanya, ialah senarai terpaut yang menguruskan halaman cache percuma Jika halaman cache tidak digunakan, blok kawalannya akan disambungkan senarai pautan percuma.

Sambungkan blok kawalan melalui nod asas untuk membentuk senarai terpaut percuma dan simpan maklumat asas seperti bilangan halaman percuma.

Apabila kami membaca halaman dari cakera ke dalam kumpulan penimbal, kami akan mengambil blok kawalan percuma dan mengisi maklumat asas halaman cache yang sepadan.

Pemprosesan cincang halaman cache

Bagaimanakah MySQL cepat mengakses halaman dalam kumpulan penimbal dan menyemak sama ada halaman yang sepadan telah dicache dalam kumpulan penimbal?

Ini menggunakan jadual cincang, iaitu peta cincang dalam Java Ruang jadual + nombor halaman diproses untuk membentuk nilai kunci cincang, dan kemudian nilai nilai ialah alamat halaman cache dalam penimbal. kolam.

Pengurusan senarai terpaut flush

Saya terkejut apabila saya mempelajari bab ini Pertama sekali, ia memang berbeza dengan pemahaman saya, dan MVCC yang kemudiannya benar-benar membuatkan saya pembuka mata ini adalah ringkasan yang saya buat setelah mengkajinya sekali, jadi ia agak padat dan padat.

Apabila kami menggunakan pernyataan SQL untuk mengubah suai rekod tertentu, kami akan mengubah suai halaman tertentu atau berbilang halaman Apabila kami mengubah suai halaman, kami tidak akan membuat pengubahsuaian yang sepadan secara langsung pada cakera IO terlalu perlahan, kami mula-mula akan memautkan halaman yang diubah suai (pendeknya halaman kotor), yang serupa dengan senarai pautan percuma, iaitu, nod asas menghubungkan blok kawalan yang sepadan dengan halaman kotor bersama-sama.

Senarai terpaut siram ini mewakili senarai terpaut yang belum kami kemas kini halaman ke cakera.

Senarai terpaut LRU

Oleh kerana saiz kolam penampan adalah terhad, saiz halaman cache kami adalah terhad, jadi kami perlu mengasingkan halaman yang tidak digunakan Buat penyingkiran. MySQL menggunakan kaedah LRU untuk penghapusan.

LRU ialah strategi penghapusan terpanjang yang tidak digunakan Kami menggunakan senarai terpaut untuk memautkan halaman yang paling baru diakses muncul di bahagian hadapan, dan halaman yang paling kurang diakses berada di penghujung senarai terpaut LRU penuh, halaman baharu akan masuk. Hapuskan halaman ekor senarai terpaut.

Kami menggunakan LRU secara langsung Apabila MySQL melakukan prabacaan atau pengimbasan jadual penuh, sejumlah besar halaman frekuensi rendah dibaca ke dalam senarai terpaut LRU, yang akan menyebabkan halaman frekuensi tinggi dihapuskan secara langsung. digantikan dengan beberapa halaman yang jarang digunakan.

Pengoptimum MySQL akan pramuat halaman yang dijangka boleh diakses oleh pertanyaan ke dalam kumpulan penimbal memori untuk meningkatkan prestasi pertanyaan. Ia boleh dibahagikan kepada dua jenis:

• Baca ke hadapan linear

Apabila membaca halaman dalam kawasan melebihi nilai pembolehubah sistem innodb_read_ahead_threshold , nilai lalai ialah 56. Maksudnya, apabila kita membaca lebih daripada 56 halaman dalam satu kawasan, MySQL akan secara tak segerak membaca semua halaman di kawasan seterusnya ke dalam ingatan.

• Prabacaan rawak

Jika kumpulan penimbal telah mencache 13 halaman di kawasan tertentu, tidak kira sama ada berurutan atau tidak, selagi terdapat 13 Setelah halaman dicache, MySQL akan dicetuskan untuk membaca secara tak segerak semua halaman di kawasan ini ke dalam MySQL. Pembolehubah sistem innodb_random_read_ahead boleh ditetapkan untuk mematikan bacaan ke hadapan rawak. Lalai adalah MATI.

Jadi terdapat senarai terpaut LRU berasaskan partition yang dipertingkatkan, yang membahagikan senarai terpaut kepada dua bahagian.

Satu kawasan muda yang sangat kerap digunakan, dan satu lagi kawasan lama yang tidak begitu kerap digunakan.

正常来说old区占比是37％，所以young区就占63％，我们可以通过innodb_old_blocks_pct来修改，默认就是37。

我们来讲讲这个基于分区的LRU链表。

1. 首先buffer pool初始化，会将读取的页面直接放进old区。

• 但是如果我们对于同一个页面的多条记录进行访问的话，我们就会多次访问同一页多次。但是如果我们是全表扫描的话，是可能会将所有页面缓存进缓存池中的，所以MySQL对于其进行优化。

• 所以MySQL对于当页面第一次读入old区并在一定时间间隔（innodb_old_blocks_pct）内的多次访问来说是不会将其放入young区进行缓存的。innodb_old_blocks_pct的值默认为1000，就是刚来的来一秒内的多次访问是不会将其转移到young区的。

1. 如果多次访问就会将old区的页升级到young区。当young区的页面被访问，只有young链表后1/4的页面被访问时才会将其转置到young区链表头，不然就不会改动，减少一些调整链表的性能损失。

刷新脏页

MySQL会启动后台线程进行脏页，也就是修改的页面进行刷新到磁盘。

以下有两种方式刷新脏页：

• 从LRU的尾部扫描一些页面，刷新其中的脏页到磁盘中。

• 在LRU链表的old区域尾部，即不经常使用的页面中，后台线程会查找是否存在脏页，如果有，则将其更新至磁盘。控制扫描区域尾部数量的方法是更改系统变量innodb_lru_scan_depth。

• 从flush链表中更新到磁盘。

• 我们上面说了flush连接这脏页的控制块，我们就可以将连接这flush链表的脏页进行更新。

疑问：为什么要两种方式更新呢？我刚开始不懂这是我回过头来看的时候就懂了

首先我们脏页是缓存在buffer pool中的，但是我们buffer pool空间是有限的，又因为我们使用的是LRU的方式，又因为从flush链表将脏页同步到磁盘效率实在不高，所以不会很经常去更新脏页。如果我们不更新直接将其从LRU的链表抛弃也就是从缓存池中直接扔了，但是它是脏页就无法同步到磁盘了，同时flush链表链接的也会出现问题。

所以在LRU淘汰很久未使用的页有个前提就是它不是一个脏页。为了淘汰这些页面，我们需要检查LRU链表的末尾是否存在脏页并进行更新。

flush链表更新那就是它的本职工作了，它存这个也是干这个的，应该没有什么问题。

当系统十分繁忙，buffer pool使用量不足的时候，因为磁盘IO太慢了，所以会出现一种情况，就是大量的用户线程也在进行这个同步脏页的活。如果未进行脏页同步并淘汰缓冲池的页面，则无法读取该页面。

多个buffer pool实例

我们可以设置多个buffer pool来实现多实例提高性能。

mysql> show variables like 'innodb_buffer_pool_instances';
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| innodb_buffer_pool_instances | 1     |
+------------------------------+-------+
1 row in set, 1 warning (0.00 sec)

我们可以设置innodb_buffer_pool_instances系统变量来控制实例变量。

但是当buffer pool的大小小于1G的时候，设置2个实例也是没有用的（会被恢复成1个），多实例的情况是建立在大内存的情况下的。

动态调整buffer pool大小

在MySQL5.7.5后，MySQL中的buffer pool的大小是以chunk来分配了，如下图。

一个buffer pool是由多个chunk组成的，所以MySQL向操作系统申请连续的内存空间，就是以chunk的方式来申请的，这样我们可以在MySQL运行时调整buffer pool的大小。在运行时更改chunk大小不可行，并且会造成性能浪费。？

innodb_buffer_pool_size / innodb_buffer_pool_instances = 每个实例buffer pool的大小。

每个实例的大小 / innodb_buffer_pool_chunk_size = 每个实例由多少个chunk构成。

不是弄很明白，怎么动态调整大小，我调整了但是mysqld占用内存大小还是只能重启才能生效，我不会。

查看buffer pool具体的信息

show engine innodb status;

Atas ialah kandungan terperinci Apakah mata pengetahuan tentang membaca kumpulan penimbal halaman dalam MySQL?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!