Penjelasan terperinci tentang seni bina mysql yang menarik dan pengetahuan enjin storan InnoDB

Artikel ini membawa anda pengetahuan tentang seni bina termaju MYSQL dan enjin storan InnoDB saya harap ia akan membantu anda.

Rajah seni bina asas MySQL

Secara amnya, MySQL boleh dibahagikan kepada dua bahagian: Lapisan pelayan dan lapisan enjin storan.

Lapisan Pelayan termasuk penyambung, cache pertanyaan, penganalisis, pengoptimum, pelaksana, dsb., meliputi kebanyakan fungsi perkhidmatan teras MySQL, serta semua fungsi terbina dalam (seperti tarikh, masa, matematik dan penyulitan fungsi, dsb. ), semua fungsi enjin storan silang dilaksanakan dalam lapisan ini, seperti prosedur tersimpan, pencetus, pandangan, dsb.

Penyambung

Penyambung ialah apa yang anda gunakan semasa menyambung ke pangkalan data Ia bertanggungjawab untuk mewujudkan sambungan dengan pelanggan, mendapatkan kebenaran, mengekalkan dan mengurus sambungan .

Arahan: mysql -h$ip -P$port -u$user -p, tekan Enter dan masukkan kata laluan Anda juga boleh memasukkan kata laluan selepas -p, tetapi terdapat risiko kebocoran kata laluan.

tunjukkan senarai proses, anda boleh menyemak status sambungan Terdapat Tidur dalam lajur Perintah untuk menunjukkan bahawa sambungan melahu.

Sambungan melahu akan diputuskan sambungan selepas 8 jam secara lalai dan boleh dikonfigurasikan oleh parameter tunggu_masa tamat.

Dalam pangkalan data, sambungan yang panjang bermakna selepas sambungan berjaya, jika pelanggan terus membuat permintaan, sambungan yang sama akan sentiasa digunakan. Sambungan pendek bermakna sambungan diputuskan selepas beberapa pertanyaan dilaksanakan dan yang baharu diwujudkan semula untuk pertanyaan seterusnya.

Memandangkan mewujudkan sambungan menggunakan lebih banyak sumber, adalah disyorkan untuk menggunakan sambungan yang panjang seberapa banyak yang mungkin, bagaimanapun, selepas menggunakan sambungan yang lama, memori yang diduduki oleh MySQL meningkat dengan cepat Ini kerana memori digunakan buat sementara waktu MySQL semasa pelaksanaan diuruskan semasa sambungan di dalam objek. Sumber ini akan dikeluarkan apabila sambungan diputuskan. Oleh itu, jika sambungan lama terkumpul, mereka mungkin menduduki terlalu banyak memori dan dibunuh secara paksa oleh sistem (OOM Berdasarkan fenomena itu, MySQL dimulakan semula secara tidak normal).

Penyelesaian:

Putuskan sambungan sambungan yang panjang dengan kerap. Selepas menggunakannya untuk tempoh masa, atau selepas program menentukan bahawa pertanyaan besar yang menggunakan memori telah dilaksanakan, sambungan diputuskan, dan kemudian pertanyaan diperlukan dan kemudian disambungkan semula.

Jika anda menggunakan MySQL 5.7 atau lebih baharu, anda boleh memulakan semula sumber sambungan dengan melaksanakan mysql_reset_connection selepas setiap operasi besar. Proses ini tidak memerlukan penyambungan semula dan pengesahan kebenaran, tetapi akan memulihkan sambungan kepada keadaan apabila ia baru dibuat.

Cache pertanyaan

Cache cache penyataan yang dilaksanakan sebelum ini dan keputusannya dalam memori dalam bentuk pasangan nilai kunci. Kuncinya ialah pernyataan pertanyaan, dan nilainya ialah hasil pertanyaan. Jika pertanyaan anda boleh mencari kunci terus dalam cache ini, maka nilai akan dikembalikan terus kepada klien.

Cache pertanyaan telah dialih keluar dalam MYSQL8 Disebabkan oleh kegagalan cache pertanyaan yang kerap, kadar hit adalah rendah.

Penganalisis

Penganalisis akan terlebih dahulu melakukan "analisis leksikal" untuk mengenal pasti apakah rentetan di dalamnya dan apa yang diwakilinya. Kemudian anda perlu melakukan "analisis sintaks" untuk menentukan sama ada pernyataan SQL yang anda masukkan memenuhi sintaks MySQL.

Pengoptimum

Pelaksana

Lapisan enjin storan bertanggungjawab untuk penyimpanan dan pengambilan semula data. Model seni binanya adalah pemalam dan menyokong berbilang enjin storan seperti InnoDB, MyISAM dan Memory. Enjin storan yang paling biasa digunakan sekarang ialah InnoDB, yang telah menjadi enjin storan lalai sejak MySQL versi 5.5.5.

Proses pelaksanaan pernyataan Pilih

Rajah di atas mengambil enjin storan InnoDB sebagai contoh. Proses pemprosesan adalah seperti berikut :

• Pengguna menghantar permintaan kepada tomcat, mewujudkan sambungan melalui kolam pautan tomcat dan kolam sambungan mysql, dan kemudian menghantar pernyataan SQL ke MySQL melalui sambungan;

• MySQL mempunyai urutan pendengaran yang berasingan, yang membaca data permintaan dan mendapatkan pernyataan SQL yang diminta dalam sambungan itu; data SQL yang diperolehi ke antara muka SQL untuk pelaksanaan; pengoptimum untuk mencari pertanyaan yang optimum Kekuatan jalan kemudiannya dihantar kepada pelaksana;

• Sebagai contoh, pelaksana boleh terlebih dahulu memanggil antara muka enjin storan untuk mendapatkan baris pertama data dalam jadual "pengguna", dan kemudian menentukan medan "id" data ini nilai yang sama dengan nilai yang kami jangkakan? Jika tidak, teruskan memanggil antara muka enjin storan untuk mendapatkan baris data seterusnya dalam jadual "pengguna". Berdasarkan idea di atas, pelaksana akan menggunakan satu set rancangan pelaksanaan yang dijana oleh pengoptimum kami, dan kemudian terus memanggil pelbagai antara muka enjin storan untuk melengkapkan pelan pelaksanaan pernyataan SQL, yang secara kasarnya adalah untuk mengemas kini atau mengekstrak Beberapa secara berterusan data keluar.

Terdapat beberapa soalan yang terlibat di sini:

Apakah sebenarnya pemacu MySQL?

Ambil java sebagai contoh Jika kita ingin mengakses pangkalan data MySQL dalam sistem Java, kita mesti menambah pemacu MySQL pada kebergantungan sistem Sebagai contoh, tambahkan

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.46</version>
</dependency>

pada Maven 🎜>Jadi apa sebenarnya pemacu MySQL ini sebenarnya, pemacu L akan mewujudkan sambungan rangkaian dengan pangkalan data di peringkat bawah Apabila terdapat sambungan rangkaian, ia kemudiannya boleh menghantar permintaan ke pelayan pangkalan data! Biarkan sistem yang ditulis dalam bahasa mengakses pangkalan data melalui pemacu MySQL, seperti yang ditunjukkan di bawah

Apakah kumpulan sambungan pangkalan data digunakan?

Andaikan perkhidmatan web dibangunkan di Java dan digunakan pada Tomcat boleh memproses permintaan secara serentak dengan berbilang rangkaian, jadi perkara pertama adalah mustahil untuk membuat hanya satu sambungan pangkalan data (berbilang permintaan untuk mendapatkan satu sambungan. , ia jauh lebih cekap rendah).

Kedua, bagaimana jika sambungan pangkalan data dibuat untuk setiap permintaan Ini juga sangat buruk, kerana sangat memakan masa untuk mewujudkan sambungan pangkalan data setiap kali Tidak mudah untuk mewujudkan sambungan dan melaksanakan pernyataan SQL , ia juga memusnahkan sambungan pangkalan data, menyebabkan masalah prestasi disebabkan oleh penciptaan dan pemusnahan yang kerap.

Jadi pengumpulan sambungan pangkalan data biasanya digunakan, iaitu, berbilang sambungan pangkalan data dikekalkan dalam kumpulan, membenarkan berbilang benang menggunakan sambungan pangkalan data yang berbeza di dalam untuk melaksanakan pernyataan SQL, dan kemudian tidak memusnahkannya selepas melaksanakan SQL penyata. Sambungan pangkalan data ini sebaliknya meletakkan sambungan semula ke dalam kumpulan dan boleh terus digunakan pada masa hadapan. Berdasarkan mekanisme kumpulan sambungan pangkalan data sedemikian, masalah berbilang benang secara serentak menggunakan sambungan pangkalan data berbilang untuk melaksanakan pernyataan SQL boleh diselesaikan, dan masalah sambungan pangkalan data yang dimusnahkan selepas digunakan juga boleh dielakkan.

Apakah kumpulan sambungan pangkalan data MySQL digunakan?

Kolam sambungan pangkalan data MySQL mempunyai fungsi yang sama seperti kumpulan sambungan aplikasi Java, dan kedua-duanya memainkan peranan untuk menggunakan semula sambungan.

Enjin storan InnoDB

Analisis ringkas seni bina InnoDB

Seperti yang dapat dilihat daripada gambar, enjin storan InnoDB terdiri daripada tiga bahagian: kolam memori, benang latar belakang dan fail cakera

Berikut adalah satu lagi gambar yang menyerlahkan perkara utama:

Enjin Storan InnoDB Bahagian 1: Struktur Memori

Kolam Penampan

Enjin storan InnoDB adalah berdasarkan storan cakera dan mengurus rekod dalam halaman Walau bagaimanapun, disebabkan jurang antara kelajuan CPU dan kelajuan cakera, sistem pangkalan data berasaskan cakera biasanya menggunakan rekod kumpulan penimbal untuk meningkatkan prestasi keseluruhan pangkalan data.

Lakukan operasi baca dalam pangkalan data dan letakkan halaman dibaca dari cakera dalam kumpulan penimbal Pada kali berikutnya halaman yang sama dibaca, mula-mula tentukan sama ada halaman itu berada dalam kumpulan penimbal. Jika ia berada dalam kolam penampan, ia dikatakan bahawa halaman itu dipukul dalam kolam penampan dan halaman dibaca secara langsung. Jika tidak, halaman pada cakera dibaca.

Untuk operasi pengubahsuaian halaman dalam pangkalan data, halaman dalam kumpulan penimbal diubah suai dahulu, dan kemudian dimuat semula ke cakera pada frekuensi tertentu Operasi menyegarkan halaman dari kumpulan penimbal kembali ke cakera tidak berlaku setiap kali halaman Dicetuskan semasa kemas kini, tetapi dibuang kembali ke cakera melalui mekanisme yang dipanggil CheckPoint. Oleh itu, saiz kumpulan penimbal secara langsung mempengaruhi prestasi keseluruhan pangkalan data Ia boleh ditetapkan melalui parameter konfigurasi innodb_buffer_pool_size Kumpulan penimbal lalai ialah 128MB, yang masih kecil jika pangkalan data anda adalah 16-teras mesin, maka anda boleh memberikan Buffer Pool memperuntukkan 2GB memori.

Memandangkan kumpulan penimbal tidak terhingga, kerana halaman data pada cakera dimuatkan secara berterusan ke dalam kumpulan penimbal, kumpulan penimbal akan sentiasa digunakan pada masa ini, beberapa halaman cache hanya boleh dihapuskan. Kaedahnya adalah dengan menggunakan algoritma yang paling kurang digunakan (LRU) Secara khusus, ia adalah untuk memperkenalkan senarai terpaut LRU yang baru ini, anda boleh mengetahui halaman cache yang paling kurang digunakan naikkan halaman cache Apabila mengepam ke cakera, anda boleh memilih halaman cache yang paling kurang digunakan baru-baru ini dalam senarai LRU untuk dihapuskan.

Jenis halaman data yang dicache dalam kumpulan penimbal termasuk: halaman indeks, halaman data, halaman buat asal, penimbal sisipan, indeks cincang suai, maklumat kunci dan maklumat kamus data yang disimpan dalam InnoDB.

Halaman data dan halaman indeks

Halaman (Halaman) ialah struktur paling asas bagi storan Innodb dan unit terkecil bagi pengurusan cakera Innodb. Semua yang berkaitan dengan pangkalan data adalah Disimpan dalam struktur Halaman. Halaman dibahagikan kepada beberapa jenis, dan halaman data dan halaman indeks ialah dua jenis yang paling penting.

Sisipkan Penimbal

Apabila memasukkan pada enjin InnoDB, secara amnya adalah perlu untuk memasukkan mengikut urutan kunci utama, untuk mendapatkan prestasi sisipan yang lebih tinggi. Apabila terdapat indeks bukan unik yang tidak berkelompok dalam jadual, apabila memasukkan, halaman data masih disimpan mengikut urutan mengikut kunci utama, tetapi pemasukan nod daun indeks tidak berkelompok tidak lagi berurutan , adalah perlu Akses diskret kepada halaman indeks bukan berkelompok membawa kepada kemerosotan prestasi operasi sisipan kerana kehadiran bacaan rawak.

Jadi enjin storan InnoDB mempelopori reka bentuk Insert Buffer Untuk operasi sisipan atau kemas kini indeks bukan berkelompok, ia tidak dimasukkan terus ke dalam halaman indeks setiap kali, tetapi terlebih dahulu menentukan sama ada yang dimasukkan bukan berkelompok. halaman indeks berada dalam halaman indeks Dalam kolam penampan, jika ia ada, ia akan dimasukkan terus jika ia tidak ada, ia akan dimasukkan ke dalam objek Penampan Sisipkan, yang nampaknya menipu. Indeks pangkalan data tidak berkelompok telah dimasukkan ke dalam nod daun, tetapi sebenarnya ia tidak disimpan di lokasi lain. Kemudian lakukan operasi gabungan Penampan Sisipan dan sub-nod halaman indeks tambahan pada frekuensi dan situasi tertentu Pada masa ini, berbilang sisipan biasanya boleh digabungkan menjadi satu operasi (kerana ia berada dalam satu halaman indeks), yang. mempertingkatkan prestasi yang lebih baik untuk sisipan indeks bukan berkelompok.

Walau bagaimanapun, penggunaan Insert Buffer perlu memenuhi dua syarat berikut pada masa yang sama:

• Indeks ialah indeks sekunder (indeks sekunder);

• Indeks tidak unik.

Apabila dua syarat di atas dipenuhi, enjin storan InnoDB akan menggunakan Penampan Sisip, yang boleh meningkatkan prestasi operasi sisipan. Tetapi pertimbangkan situasi di mana aplikasi melakukan sejumlah besar operasi sisipan, yang semuanya melibatkan indeks bukan berkelompok yang tidak unik, iaitu, penggunaan Penampan Sisip. Jika pangkalan data MySQL turun pada masa ini, akan terdapat sejumlah besar Penampan Sisipan yang tidak digabungkan ke dalam indeks bukan berkelompok sebenar.

Jadi pemulihan mungkin mengambil masa yang lama, malah beberapa jam dalam kes yang teruk. Indeks tambahan tidak boleh unik kerana apabila memasukkan penimbal, pangkalan data tidak mencari halaman indeks untuk menentukan keunikan rekod yang dimasukkan. Jika anda mencari, pasti akan terdapat bacaan diskret, yang akan menyebabkan Insert Buffer kehilangan maknanya.

Anda boleh melihat maklumat penimbal sisipan melalui arahan SHOW ENGINE INNODB STATUS

saiz seg menunjukkan saiz Insert Buffer semasa ialah 11336×16KB, iaitu kira-kira 177MB len senarai percuma mewakili panjang senarai percuma mewakili bilangan halaman rekod yang digabungkan. Baris kedua dalam huruf tebal mungkin perkara yang pengguna benar-benar mengambil berat tentang, kerana ia menunjukkan peningkatan dalam prestasi sisipan. Sisipan mewakili bilangan rekod yang dicantumkan mewakili bilangan cantuman yang disisipkan mewakili bilangan cantuman, iaitu bilangan bacaan halaman sebenar. merges: merged recs ialah kira-kira 1:3, yang bermaksud penimbal sisipan mengurangkan permintaan logik IO diskret untuk halaman indeks bukan berkelompok sebanyak kira-kira 2/3.

Seperti yang dinyatakan sebelum ini, pada masa ini terdapat masalah dengan Insert Buffer: dalam kes penulisan intensif, insert buffer akan menduduki terlalu banyak memori pool buffer (innodb buffer pool Secara lalai, ia boleh menduduki sehingga 1/2 memori kolam penimbal. Berikut ialah operasi permulaan untuk penimbal sisipan dalam kod sumber enjin storan InnoDB:

Tukar Penampan

InnoDB daripada versi 1.0 .x Change Buffer telah diperkenalkan, yang boleh dianggap sebagai versi Insert Buffer yang dipertingkatkan Enjin storan InnodB boleh menampan operasi DML - INSERT, DELETE dan UPDATE Ia adalah: Insert Buffer, Delete Buffer, Purge buffer, dan sudah tentu Sisipan Seperti Penampan sebelumnya, objek yang digunakan untuk Tukar Penampan masih merupakan indeks tambahan bukan unik.

Operasi KEMASKINI pada rekod boleh dibahagikan kepada dua proses:

• Tandakan rekod sebagai dipadamkan; rekod

• Oleh itu, Penampan Padam sepadan dengan proses pertama operasi KEMASKINI, iaitu menandakan rekod untuk pemadaman. PurgeBuffer sepadan dengan proses kedua operasi KEMASKINI, yang akan merekodkan pemadaman sebenar. Pada masa yang sama, enjin storan InnoDB menyediakan parameter innodb_change_buffering, yang digunakan untuk mendayakan pelbagai pilihan Buffer. Nilai pilihan parameter ini ialah: Sisipan, padam, pembersihan, perubahan, semua, tiada. Sisipan, pemadaman dan pembersihan adalah tiga situasi yang dibincangkan sebelum ini. perubahan bermakna mendayakan Sisipan dan pemadaman, semua bermakna mendayakan semua dan tiada satu pun bermakna tidak membolehkan tiada. Nilai lalai parameter ini ialah semua.

  从 InnoDB1.2.x版本开始,可以通过参数 innodb_change_buffer_max_size 来控制Change Buffer最大使用内存的数量:

  mysql> show variables like 'innodb_change_buffer_max_size';
  +-------------------------------+-------+
  | Variable_name                 | Value |
  +-------------------------------+-------+
  | innodb_change_buffer_max_size | 25    |
  +-------------------------------+-------+
  1 row in set (0.05 sec)

  innodb_change_buffer_max_size 值默认为25,表示最多使用1/4的缓冲池内存空间。

  而需要注意的是,该参数的最大有效值为50在 MySQL5.5版本中通过命令 SHOW ENGINE INNODB STATUS,可以观察到类似如下的内容:

  

  可以看到这里显示了 merged operations和 discarded operation,并且下面具体显示 Change Buffer中每个操作的次数。 Insert 表示 Insert Buffer; delete mark表示 Delete Buffer; delete表示 Purge Buffer; discarded operations表示当 Change Buffer发生 merge时,表已经被删除,此时就无需再将记录合并(merge)到辅助索引中了。

  自适应哈希索引

  InnoDB 会根据访问的频率和模式，为热点页建立哈希索引，来提高查询效率。InnoDB 存储引擎会监控对表上各个索引页的查询，如果观察到建立哈希索引可以带来速度上的提升，则建立哈希索引，所以叫做自适应哈希索引。

  自适应哈希索引通过缓冲池的B+树页构建而来，因此建立速度很快，而且不需要对整张数据表建立哈希索引。其有一个要求，即对这个页的连续访问模式必须一样的，也就是说其查询的条件必须完全一样，而且必须是连续的。

  锁信息（lock info）

  我们都知道，InnoDB 存储引擎会在行级别上对表数据进行上锁，不过 InnoDB 打开一张表，就增加一个对应的对象到数据字典。

  数据字典

  对数据库中的数据、库对象、表对象等的元信息的集合。在 MySQL 中，数据字典信息内容就包括表结构、数据库名或表名、字段的数据类型、视图、索引、表字段信息、存储过程、触发器等内容，MySQL INFORMATION_SCHEMA 库提供了对数据局元数据、统计信息、以及有关MySQL Server的访问信息（例如：数据库名或表名，字段的数据类型和访问权限等）。该库中保存的信息也可以称为MySQL的数据字典。

  预读机制

  MySQL的预读机制，就是当你从磁盘上加载一个数据页的时候，他可能会连带着把这个数据页相邻的其他数据页，也加载到缓存里去！

  举个例子，假设现在有两个空闲缓存页，然后在加载一个数据页的时候，连带着把他的一个相邻的数据页也加载到缓存里去了，正好每个数据页放入一个空闲缓存页！

  哪些情况下会触发MySQL的预读机制？

  • 有一个参数是innodb_read_ahead_threshold，他的默认值是56，意思就是如果顺序的访问了一个区里的多个数据页，访问的数据页的数量超过了这个阈值，此时就会触发预读机制，把下一个相邻区中的所有数据页都加载到缓存里去。

  • 如果Buffer Pool里缓存了一个区里的13个连续的数据页，而且这些数据页都是比较频繁会被访问的，此时就会直接触发预读机制，把这个区里的其他的数据页都加载到缓存里去这个机制是通过参数innodb_random_read_ahead来控制的，他默认是OFF，也就是这个规则是关闭的。

  所以默认情况下，主要是第一个规则可能会触发预读机制，一下子把很多相邻区里的数据页加载到缓存里去。

  预读机制的好处为了提升性能。假设你读取了数据页01到缓存页里去，那么接下来有可能会接着顺序读取数据页01相邻的数据页02到缓存页里去，这个时候，是不是可能在读取数据页02的时候要再次发起一次磁盘IO？

  所以为了优化性能，MySQL才设计了预读机制，也就是说如果在一个区内，你顺序读取了好多数据页了，比如数据页01到数据页56都被你依次顺序读取了，MySQL会判断，你可能接着会继续顺序读取后面的数据页。那么此时就提前把后续的一大堆数据页（比如数据页57到数据页72）都读取到Buffer Pool里去。

  缓冲池内存管理

  这里需要了解三个链表（Free List、Flush List、LRU List），

  • Halaman data dan halaman cache pada cakera Senarai Percuma berada dalam surat-menyurat satu dengan satu, kedua-duanya adalah 16KB dan satu halaman data sepadan dengan satu halaman cache. Pangkalan data akan mereka bentuk senarai terpaut percuma untuk Buffer Pool, iaitu struktur data senarai terpaut dua hala Dalam senarai terpaut percuma ini, setiap nod ialah alamat halaman cache percuma yang menerangkan blok data selagi satu halaman cache adalah percuma, maka blok data penerangannya akan dimasukkan ke dalam senarai terpaut percuma ini. Apabila pangkalan data mula-mula dimulakan, semua halaman cache mungkin percuma, kerana ia mungkin pangkalan data kosong tanpa data sama sekali, jadi blok data penerangan semua halaman cache akan dimasukkan ke dalam senarai terpaut percuma pada masa ini , senarai terpaut percuma ini mempunyai nod asas, yang merujuk kepada nod kepala dan nod ekor senarai terpaut Ia juga menyimpan berapa banyak nod yang menerangkan blok data terdapat dalam senarai terpaut, iaitu, berapa banyak halaman cache percuma yang ada. .

  • Senarai Siram adalah serupa dengan senarai terpaut Senarai Percuma Intipati senarai pautan siram adalah menggunakan dua penunjuk dalam blok data penerangan halaman cache untuk membuat blok data perihalan. halaman cache yang diubah suai. Mana-mana halaman cache yang telah diubah suai akan mempunyai blok data perihalannya yang ditambahkan pada senarai terpaut siram bermakna halaman ini kotor dan ia akan disiram ke cakera pada masa hadapan.
    

  • Senarai LRU Memandangkan saiz kumpulan penimbal adalah pasti, dengan kata lain, data halaman cache percuma dalam senarai terpaut percuma adalah pasti apabila anda terus mengalihkan data cakera Halaman dimuatkan ke dalam halaman cache percuma, dan halaman cache percuma sentiasa dialih keluar dari senarai terpaut percuma Lambat laun, tidak akan ada halaman cache percuma dalam senarai terpaut percuma disingkirkan. Ini memerlukan penggunaan kadar hit cache Yang paling banyak hit cache biasanya digunakan dan yang tidak biasa digunakan boleh dihapuskan. Oleh itu, senarai pautan LRU diperkenalkan untuk menentukan halaman cache yang tidak biasa digunakan.
    

  Apakah strategi penghapusan senarai terpaut LRU?

  Andaikan apabila kita memuatkan halaman data dari cakera ke halaman cache, kita meletakkan blok data penerangan halaman cache ini ke dalam kepala senarai terpaut LRU Kemudian selagi ada halaman cache dengan data, ia akan berada dalam LRU , dan halaman cache yang baru-baru ini telah dimuatkan dengan data akan diletakkan di kepala senarai terpaut LRU, dan kemudian halaman cache tertentu ditambahkan pada ekor pertanyaan berlaku, ia akan dialihkan ke kepala, dan kemudian ekor perlu dihapuskan.

  

  Tetapi adakah ini benar-benar okay?

  Kes pertama ialah mekanisme baca hadapan dimusnahkan

  Memandangkan mekanisme baca hadapan akan memuatkan halaman data bersebelahan yang belum diakses ke dalam cache, hanya satu halaman cache sebenarnya diakses. Kini, satu lagi halaman cache yang dimuatkan melalui mekanisme baca ke hadapan sebenarnya tidak diakses oleh sesiapa Pada masa ini, kedua-dua halaman cache ini boleh berada di hadapan senarai terpaut LRU, seperti yang ditunjukkan di bawah

  

  Pada masa ini, jika tiada halaman cache percuma, maka halaman data baharu perlu dimuatkan pada masa ini Adakah perlu untuk mengeluarkan apa yang dipanggil "halaman cache yang paling kurang digunakan baru-baru ini". penghujung senarai terpaut LRU dan siramkannya ke cakera , dan kemudian kosongkan halaman cache percuma. Ini jelas sangat tidak munasabah.
  Situasi kedua mungkin menyebabkan halaman cache yang kerap diakses akan dihapuskan
  Imbasan jadual penuh menyebabkan dia memuatkan terus semua halaman data dalam jadual daripada cakera sekali gus Pergi ke Kolam Penampan. Pada masa ini, semua halaman data jadual ini boleh dimuatkan ke dalam setiap halaman cache satu demi satu! Pada masa ini, ada kemungkinan bahawa senarai besar halaman cache di hadapan senarai terpaut LRU adalah semua halaman cache dimuatkan melalui imbasan jadual penuh! Jadi bagaimana jika selepas imbasan jadual penuh ini, data dalam jadual ini hampir tidak digunakan pada masa hadapan? Pada masa ini, ekor senarai terpaut LRU mungkin semua halaman cache yang telah kerap diakses sebelum ini! Kemudian apabila anda ingin menghapuskan beberapa halaman cache untuk memberi ruang, anda akan menghapuskan halaman cache yang telah kerap diakses pada penghujung senarai LRU, meninggalkan sejumlah besar halaman yang jarang diakses yang dimuatkan dalam imbasan jadual penuh sebelumnya. Halaman cache!
  Optimumkan algoritma LRU: reka senarai terpaut LRU berdasarkan idea pengasingan data panas dan sejuk
  Apabila MySQL mereka bentuk senarai terpaut LRU, ia sebenarnya menggunakan idea ​mengasingkan data panas dan sejuk. Senarai terpaut LRU akan dibahagikan kepada dua bahagian, satu adalah data panas dan satu lagi adalah data sejuk Nisbah data panas dan sejuk dikawal oleh parameter innodb_old_blocks_pct, yang bermaksud bahawa data sejuk menyumbang 37 %. Apabila halaman data dimuatkan ke dalam cache buat kali pertama, halaman cache sebenarnya akan diletakkan di kepala senarai terpaut dalam kawasan data sejuk.

  

  Kemudian MySQL menetapkan peraturan Dia mereka bentuk parameter innodb_old_blocks_time. Nilai lalai ialah 1000, dengan kata lain, selepas halaman data dimuatkan ke dalam halaman cache. ia akan dialihkan ke kepala senarai terpaut dalam kawasan data panas. Kerana andaikan anda memuatkan halaman data ke dalam cache, dan kemudian anda mengakses halaman cache ini selepas 1s, yang bermaksud bahawa anda mungkin akan kerap mengaksesnya pada masa hadapan Had masa ialah 1s, jadi anda hanya mengakses halaman cache ini selepas 1s . Halaman cache, dia akan meletakkan halaman cache ke dalam kepala senarai terpaut di kawasan data panas untuk anda.

  

  Dalam kes ini, data untuk prabacaan dan imbasan jadual penuh hanya akan berada dalam pengepala data sejuk dan tidak akan memasuki kawasan data panas dari awal.

  Algoritma LRU sangat dioptimumkan

  Peraturan akses kawasan data panas senarai terpaut LRU dioptimumkan, iaitu, hanya halaman cache dalam 3/4 terakhir kawasan data panas adalah Selepas mengaksesnya, anda akan dialihkan ke kepala senarai terpaut. Jika 1/4 pertama halaman cache dalam kawasan data panas diakses, ia tidak akan dialihkan ke kepala senarai terpaut.

  Sebagai contoh, dengan mengandaikan terdapat 100 halaman cache dalam senarai terpaut kawasan data panas, maka 25 halaman cache teratas tidak akan dialihkan ke kepala senarai terpaut walaupun ia diakses. Tetapi untuk 75 halaman cache seterusnya, selagi ia diakses, ia akan dialihkan ke kepala senarai terpaut. Dengan cara ini, dia boleh mengurangkan pergerakan nod dalam senarai terpaut sebanyak mungkin.

  Pemasa halaman cache penghapusan senarai terpaut LRU

  Apabila MySQL melaksanakan CRUD, ia mula-mula mengendalikan sejumlah besar halaman cache dan beberapa senarai terpaut yang sepadan. Kemudian apabila halaman cache penuh, anda mesti mencari cara untuk membuang beberapa halaman cache ke cakera, kemudian mengosongkan halaman cache ini, dan kemudian memuatkan halaman data yang diperlukan ke dalam halaman cache!

  Kami sudah tahu bahawa dia menghapuskan halaman cache berdasarkan senarai terpaut LRU, jadi bilakah dia mengepam halaman cache dalam kawasan data sejuk senarai terpaut LRU ke cakera? Malah, dia mempunyai tiga peluang berikut:

  Siram beberapa halaman cache pada penghujung LRU ke cakera secara kerap

  • Urutan latar belakang menjalankan jadual yang dijadualkan Tugasan berjadual ini setiap Selepas tempoh masa, beberapa halaman cache pada penghujung kawasan data sejuk senarai terpaut LRU akan dipadamkan ke cakera, halaman cache ini akan dikosongkan, dan ia akan ditambahkan kembali ke senarai terpaut percuma.

  

  Kerap siram beberapa halaman cache dalam senarai terpaut siram ke cakera

  Jika anda hanya cache kawasan data sejuk ​​senarai terpaut LRU Tidak cukup untuk mengepam halaman ke cakera, kerana banyak halaman cache dalam kawasan data panas senarai terpaut juga boleh diubah suai dengan kerap.

  Jadi benang latar belakang ini juga akan menyiram halaman cache dalam senarai terpaut siram ke cakera apabila MySQL tidak begitu sibuk Dengan cara ini, data yang diubah suai oleh anda akan dibuang ke cakera lambat laun!

  Selagi gelombang halaman cache dalam senarai pautan flush disiram ke cakera, halaman cache ini juga akan dialih keluar daripada senarai pautan flush dan senarai pautan lru, dan kemudian ditambahkan pada pautan percuma senaraikan!

  Jadi kesan keseluruhannya adalah untuk memuatkan data secara berterusan ke dalam halaman cache, sentiasa bertanya dan mengubah suai data cache, dan kemudian halaman cache dalam senarai terpaut percuma terus berkurangan, dan halaman cache dalam siram dipautkan senarai tidak berhenti. Ia terus meningkat, dan halaman cache dalam senarai terpaut lru terus meningkat dan bergerak.

  Di sisi lain, utas latar belakang anda terus mengepam halaman cache kawasan data sejuk senarai terpaut lru dan halaman cache senarai terpaut flush ke dalam cakera untuk mengosongkan halaman cache, dan kemudian siram senarai terpaut dan senarai terpaut lru Halaman cache semakin berkurangan, dan halaman cache dalam senarai terpaut percuma semakin meningkat.

  Senarai terpaut percuma tidak mempunyai halaman cache percuma

  Jika semua senarai pautan percuma digunakan, jika anda ingin memuatkan halaman data daripada cakera ke dalam laman web percuma halaman cache pada masa ini, Pada masa ini, halaman cache akan ditemui dari hujung kawasan data sejuk senarai terpaut LRU Ia mestilah halaman cache yang paling kurang kerap digunakan! Kemudian siram ke cakera dan kosongkannya, dan kemudian muatkan halaman data ke dalam halaman cache percuma!

  Untuk meringkaskan penggunaan tiga senarai terpaut, apabila Kolam Penampan digunakan, ia sebenarnya akan kerap memuatkan halaman data daripada cakera ke dalam halaman cachenya, dan kemudian membebaskan senarai terpaut, siram senarai terpaut, dan lru Senarai terpaut akan digunakan pada masa yang sama Contohnya, apabila data dimuatkan ke halaman cache, halaman cache akan dialih keluar daripada senarai terpaut percuma, dan kemudian kepala kawasan data sejuk. Senarai terpaut lru akan diletakkan dalam halaman cache.
  

  Kemudian jika anda mengubah suai halaman cache, halaman kotor akan direkodkan dalam senarai siram, dan senarai lru juga boleh mengalihkan anda dari kawasan data sejuk ke kepala kawasan data panas. .

  Jika anda menanyakan halaman cache, maka halaman cache akan dialihkan ke kawasan data panas dalam senarai terpaut lru, atau ia mungkin dialihkan ke kepala dalam kawasan data panas.

  Buffer log Buffer buat semula log buffer

  InnoDB mempunyai kolam penimbal (pendek kata bp). bp ialah cache halaman pangkalan data Sebarang operasi pengubahsuaian kepada InnoDB terlebih dahulu akan dilakukan pada halaman bp Kemudian halaman tersebut akan ditandakan sebagai kotor (halaman kotor) dan kemudiannya, benang induk atau A benang pembersihan khusus secara berkala menulis halaman ini ke cakera (cakera atau ssd).

  Kelebihan ini ialah ia mengelakkan operasi cakera untuk setiap operasi tulis, menyebabkan sejumlah besar IO rawak boleh menggabungkan berbilang pengubahsuaian pada halaman menjadi satu operasi IO, dan penulisan tak segerak juga mengurangkan. kos. Walau bagaimanapun, jika pelayan ditutup secara tidak normal sebelum halaman kotor disiram ke cakera, operasi pengubahsuaian ini akan hilang Jika operasi tulis sedang dijalankan, pangkalan data mungkin tidak tersedia kerana fail data yang rosak.

  Untuk mengelakkan masalah di atas, Innodb menulis semua operasi pengubahsuaian pada halaman ke dalam fail khas dan menjalankan operasi pemulihan daripada fail ini apabila pangkalan data dimulakan. Teknologi ini melambatkan penyegaran halaman bp, sekali gus meningkatkan daya pemprosesan pangkalan data dan mengurangkan kependaman akses dengan berkesan. Masalah yang dibawa oleh

  ialah overhed tambahan untuk menulis operasi log semula (IO berurutan, sudah tentu pantas), dan masa yang diperlukan untuk menyambung semula operasi apabila pangkalan data bermula.

  Log buat semula terdiri daripada dua bahagian: penimbal log buat semula dan fail log buat semula (diperkenalkan dalam bahagian fail cakera). Innodb ialah enjin storan yang menyokong urus niaga Apabila urus niaga dilakukan, semua log urus niaga mesti ditulis ke fail log buat semula terlebih dahulu. Setiap kali penimbal log buat semula ditulis pada fail log buat semula, operasi fsync perlu dipanggil, kerana penimbal log buat semula hanya menulis kandungan ke sistem penimbal sistem pengendalian dahulu, dan tidak memastikan ia ditulis secara langsung ke cakera. Operasi fsync mesti dilakukan. Oleh itu, prestasi cakera juga menentukan prestasi penyerahan transaksi pada tahap tertentu (mekanisme penurunan cakera log semula akan diperkenalkan kemudian).

  

  Enjin storan InnoDB akan terlebih dahulu meletakkan maklumat log semula ke dalam penimbal log buat semula, dan kemudian siramkannya ke fail log buat semula pada frekuensi tertentu Penimbal log secara amnya tidak perlu ditetapkan dengan sangat besar, kerana penimbal log buat semula biasanya disalurkan ke fail log setiap saat. Ia boleh dikawal oleh parameter konfigurasi Innodb_log_buffer_size, yang lalai kepada 8MB.

  Double Write

  Jika Insert Buffer membawa peningkatan prestasi pada enjin storan InnoDB, maka Double wtite membawa halaman data ke kebolehpercayaan enjin storan InnoDB.

  Saiz Halaman InnoDB biasanya 16KB dan pengesahan datanya juga dikira berdasarkan 16KB ini Menulis data ke cakera dilakukan dalam unit Halaman. Kami tahu bahawa kerana sistem fail bukan atom dalam kebanyakan kes untuk halaman data yang besar (seperti 16KB InnoDB), ini bermakna jika pelayan tidak berfungsi, hanya sebahagian daripada penulisan boleh dilakukan. Apabila 16K data ditulis kepada 4K, gangguan kuasa sistem berlaku dan ranap sistem berlaku Hanya sebahagian daripada penulisan yang berjaya.

  DBA yang berpengalaman mungkin berfikir bahawa jika kegagalan penulisan berlaku, MySQL boleh pulih berdasarkan log buat semula. Ini adalah kaedah, tetapi mesti difahami dengan jelas bahawa apa yang direkodkan dalam log buat semula ialah pengubahsuaian fizikal halaman, seperti mengimbangi 800, tulis rekod 'aaaa'. Jika halaman itu sendiri rosak, tidak ada gunanya melakukannya semula. MySQL menyemak jumlah semak halaman semasa proses pemulihan adalah untuk menyemak nombor transaksi terakhir halaman Apabila masalah penulisan halaman separa berlaku, halaman telah rosak dan nombor transaksi dalam halaman tidak dapat ditemui. Pada pandangan InnoDB, halaman data tersebut tidak boleh lulus pengesahan checksum dan tidak boleh dipulihkan. Walaupun kami memaksanya untuk lulus pengesahan, kami tidak boleh pulih daripada ranap sistem kerana beberapa jenis log semasa dalam InnoDB, sebahagian daripadanya adalah operasi logik, tidak boleh idempoten.

  Untuk menyelesaikan masalah ini, InnoDB melaksanakan penimbal tulis berganda Ringkasnya, sebelum menulis halaman data, ia terlebih dahulu menulis halaman data ke lokasi fail fizikal bebas (ibdata), dan kemudian menulisnya ke data. muka surat. Dengan cara ini, apabila mesin dimatikan dan dimulakan semula, jika halaman data rosak, sebelum menggunakan log buat semula, halaman itu perlu dipulihkan melalui salinan halaman, dan kemudian log buat semula dibuat semula Ini adalah penulisan dua kali . Apa yang dibawa oleh teknologi tulis dua kali kepada enjin storan innodb ialah kebolehpercayaan halaman data Teknologi tulis dua kali dianalisis di bawah

  

  如上图所示，Double Write 由两部分组成，一部分是内存中的 double write buffer，大小为2MB，另一部分是物理磁盘上共享表空间连续的128个页，大小也为2MB。在对缓冲池的脏页进行刷新时，并不直接写磁盘，而是通过 memcpy 函数将脏页先复制到内存中的该区域，之后通过 double write buffer 再分两次，每次1MB顺序地写入共享表空间的物理磁盘上，然后马上调用 fsync 函数，同步磁盘，避免操作系统缓冲写带来的问题。在完成double write 页的写入后，再将 double wirite buffer 中的页写入各个表空间文件中。

  在这个过程中，doublewrite 是顺序写，开销并不大，在完成 doublewrite 写入后，在将 double write buffer写入各表空间文件，这时是离散写入。

  如果操作系统在将页写入磁盘的过程中发生了崩溃，在恢复过程中，InnoDB 存储引擎可以从共享表空间中的double write 中找到该页的一个副本，将其复制到表空间文件中，再应用重做日志。

  InnoDB 存储引擎第二部分：后台线程

  IO 线程

  在 InnoDB 中使用了大量的 AIO（Async IO） 来做读写处理，这样可以极大提高数据库的性能。在 InnoDB 1.0 版本之前共有4个 IO Thread，分别是 write，read，insert buffer和log thread，后来版本将 read thread和 write thread 分别增大到了4个，一共有10个了。

  • - read thread ： 负责读取操作，将数据从磁盘加载到缓存page页。4个

  • - write thread：负责写操作，将缓存脏页刷新到磁盘。4个

  • - log thread：负责将日志缓冲区内容刷新到磁盘。1个

  • - insert buffer thread ：负责将写缓冲内容刷新到磁盘。1个

  Purge 线程

  事务提交之后，其使用的 undo 日志将不再需要，因此需要 Purge Thread 回收已经分配的 undo 页。show variables like '%innodb*purge*threads%';

  Page Cleaner 线程

  作用是将脏数据刷新到磁盘，脏数据刷盘后相应的 redo log 也就可以覆盖，即可以同步数据，又能达到 redo log 循环使用的目的。会调用write thread线程处理。show variables like '%innodb*page*cleaners%';

  InnoDB 存储引擎第三部分：磁盘文件

  InnoDB 的主要的磁盘文件主要分为三大块：一是系统表空间，二是用户表空间，三是 redo 日志文件和归档文件。

  二进制文件（binlong）等文件是 MySQL Server 层维护的文件，所以未列入 InnoDB 的磁盘文件中。

  系统表空间和用户表空间

  系统表空间包含 InnoDB 数据字典（元数据以及相关对象）并且 double write buffer , change buffer , undo logs 的存储区域。

  系统表空间也默认包含任何用户在系统表空间创建的表数据和索引数据。

  系统表空间是一个共享的表空间，因为它是被多个表共享的。

  系统表空间是由一个或者多个数据文件组成。默认情况下,1个初始大小为10MB，名为 ibdata1 的系统数据文件在MySQL的data目录下被创建。用户可以使用 innodb_data_file_path 对数据文件的大小和数量进行配置。

  innodb_data_file_path 的格式如下：

  innodb_data_file_path=datafile1[,datafile2]...

  用户可以通过多个文件组成一个表空间，同时制定文件的属性:

  innodb_data_file_path = /db/ibdata1:1000M;/dr2/db/ibdata2:1000M:autoextend

  这里将 /db/ibdata1 和 /dr2/db/ibdata2 两个文件组成系统表空间。如果这两个文件位于不同的磁盘上，磁盘的负载可能被平均，因此可以提高数据库的整体性能。两个文件的文件名之后都跟了属性，表示文件 ibdata1 的大小为1000MB，文件 ibdata2 的大小为1000MB，而且用完空间之后可以自动增长。

  设置 innodb_data_file_path 参数之后，所有基于 InnoDB 存储引擎的表的数据都会记录到该系统表空间中，如果设置了参数 innodb_file_per_table ，则用户可以将每个基于 InnoDB 存储引擎的表产生一个独立的用户空间。

  用户表空间的命名规则为：表名.ibd。通过这种方式，用户不用将所有数据都存放于默认的系统表空间中，但是用户表空间只存储该表的数据、索引和插入缓冲BITMAP等信息，其余信息还是存放在默认的系统表空间中。

  下图显示 InnoDB 存储引擎对于文件的存储方式，其中frm文件是表结构定义文件，记录每个表的表结构定义。

  

  Buat semula fail log dan fail arkib

  Secara lalai, terdapat dua fail bernama ib_logfile0 dan ib_logfile1 dalam direktori data enjin storan InnoDB , ini ialah fail log semula InnoDB, yang merekodkan log transaksi untuk enjin storan InnoDB.

  Apabila ralat berlaku dalam fail storan data InnoDB, fail log buat semula berguna. Enjin storan InnoDB boleh menggunakan fail log semula untuk memulihkan data kepada keadaan yang betul untuk memastikan ketepatan dan integriti data.

  Setiap enjin storan InnoDB mempunyai sekurang-kurangnya 1 fail log semula dan setiap kumpulan fail mempunyai sekurang-kurangnya 2 fail log semula, ditambah dengan ib_logfile0 dan ib_logfile1 lalai.

  Untuk mendapatkan kebolehpercayaan yang lebih tinggi, pengguna boleh menyediakan berbilang kumpulan log cermin dan meletakkan kumpulan fail berbeza pada cakera berbeza untuk meningkatkan ketersediaan tinggi log buat semula.

  Saiz setiap fail log buat semula dalam kumpulan log adalah sama dan berjalan dalam mod [tulisan gelung]. Enjin storan InnoDB mula-mula menulis semula fail log 1. Apabila fail penuh, ia akan bertukar kepada buat semula fail log 2. Apabila buat semula fail log 2 juga penuh, ia akan bertukar kepada buat semula log 1.

  Pengguna boleh menggunakan Innodb_log_file_size untuk menetapkan saiz fail log buat semula, yang mempunyai kesan yang besar terhadap prestasi enjin storan InnoDB.

  Jika fail log buat semula ditetapkan terlalu besar, pemulihan mungkin mengambil masa yang lama apabila data hilang, sebaliknya jika fail log buat semula ditetapkan terlalu kecil, fail log buat semula akan menjadi terlalu kecil , yang mengakibatkan ralat berasaskan pusat pemeriksaan memerlukan penyiraman yang kerap halaman kotor ke cakera, menyebabkan kegelisahan prestasi.

  Mekanisme penyiraman semula log

  InnoDB mematuhi WAL (tulis ke hadapan buat semula log) dan Force-log-at- untuk mengepam fail data dan fail log Terdapat dua peraturan komit, kedua-duanya memastikan ketahanan transaksi. WAL menghendaki bahawa sebelum perubahan data ditulis pada cakera, memori log masuk mesti ditulis ke cakera terlebih dahulu menghendaki apabila transaksi dilakukan, semua log yang dijana mesti dibuang ke cakera Jika log Selepas muat semula berjaya, jika pangkalan data ranap sebelum data dalam kumpulan penimbal dimuat semula ke cakera, pangkalan data boleh memulihkan data daripada log apabila dimulakan semula.

  

  Seperti yang ditunjukkan dalam rajah di atas, apabila InnoDB menukar data dalam kumpulan penimbal, ia akan terlebih dahulu menulis perubahan yang berkaitan pada penimbal log buat semula, dan kemudian memuat semulanya tepat pada masanya (seperti menyegarkan setiap mekanisme kedua) atau ditulis pada cakera apabila transaksi dilakukan, yang konsisten dengan prinsip Force-log-at-commit apabila log buat semula ditulis pada cakera, data yang diubah dalam kumpulan penimbal; akan ditulis pada cakera mengikut mekanisme pusat pemeriksaan, yang selaras dengan prinsip WAL.

  Dalam mekanisme pemasaan pusat pemeriksaan, terdapat penghakiman bahawa fail log buat semula penuh Oleh itu, seperti yang dinyatakan di atas, jika fail log buat semula terlalu kecil dan sering diisi, ia akan menyebabkan pusat pemeriksaan sering ditukar. data ditulis pada cakera, menyebabkan kegelisahan prestasi.

  Sistem fail sistem pengendalian mempunyai cache Apabila InnoDB menulis data ke cakera, ia mungkin hanya ditulis ke cache sistem fail, dan tiada "keselamatan" sebenar.

  Atribut innodb_flush_log_at_trx_commit InnoDB boleh mengawal gelagat InnoDB setiap kali transaksi dilakukan. Apabila nilai atribut ialah 0, apabila urus niaga dilakukan, log buat semula tidak akan ditulis, tetapi akan menunggu urutan utama menulis tepat pada masanya apabila nilai atribut ialah 1, apabila transaksi dilakukan, log buat semula akan ditulis ke fail Sistem menyimpan dan memanggil fsync sistem fail untuk benar-benar menulis data dalam penimbal sistem fail ke storan cakera untuk memastikan tiada kehilangan data berlaku apabila nilai atribut ialah 2, fail log juga akan ditulis; ke sistem fail apabila transaksi dilakukan Cache, tetapi tidak akan memanggil fsync, tetapi biarkan sistem fail menentukan masa untuk menulis cache ke cakera.

  Mekanisme curahan log ditunjukkan dalam rajah di bawah:

  

  Innodb_flush_log_at_commit ialah parameter asas untuk penalaan prestasi InnoDB, yang melibatkan kecekapan penulisan dan data Keselamatan InnoDB. Apabila nilai parameter adalah 0, kecekapan menulis adalah yang tertinggi, tetapi keselamatan data adalah yang paling rendah apabila nilai parameter adalah 1, kecekapan menulis adalah yang paling rendah, tetapi keselamatan data adalah yang tertinggi apabila nilai parameter adalah 2; , kedua-duanya berada pada tahap sederhana, dan secara amnya disyorkan untuk menetapkan atribut Nilai ditetapkan kepada 1 untuk keselamatan yang lebih tinggi, dan hanya apabila ditetapkan kepada 1, ketahanan urus niaga boleh dijamin.

  Gunakan kenyataan KEMASKINI untuk mengetahui lebih lanjut tentang enjin storan InnoDB

  Dengan pengenalan di atas kepada seni bina asas enjin storan InnoDB, mari analisa KEMASKINI sekali lagi Proses khusus kemas kini data.

  

  Kami membahagikan gambar ini kepada bahagian atas dan bawah Bahagian atas ialah aliran pemprosesan lapisan MySQL Server, dan bahagian bawah ialah aliran pemprosesan enjin storan MySQL InnoDB.

  Aliran pemprosesan lapisan MySQL Server

  

  Bahagian aliran pemprosesan ini tidak ada kaitan dengan enjin storan yang mana Ia diproses oleh lapisan Pelayan adalah seperti berikut:

  • Dicetuskan oleh pelbagai operasi pengguna Latar belakang pelaksanaan sql, melalui kumpulan sambungan pangkalan data yang disertakan dengan projek web: seperti dbcp, c3p0, druid, dll., mewujudkan sambungan rangkaian dengan kumpulan sambungan pangkalan data pelayan pangkalan data;

  • dalam kumpulan sambungan pangkalan data Selepas utas memantau permintaan, ia bertindak balas kepada penghurai pertanyaan melalui antara muka SQL dengan pernyataan sql yang diterima Penghurai pertanyaan menghuraikan sql mengikut sql sintaks untuk menentukan medan jadual mana yang hendak ditanya dan apakah syarat pertanyaan;

  • Kemudian pelaksana bertanggungjawab untuk memanggil satu siri antara muka enjin storan untuk melaksanakan Pelan ini melengkapkan pelaksanaan keseluruhan pernyataan sql

  • Bahagian ini proses itu pada asasnya konsisten dengan analisis proses pemprosesan permintaan Pilih yang dianalisis di atas.

  Aliran pemprosesan enjin storan InnoDB

  Pernyataan pelaksanaan khusus mesti dilengkapkan oleh enjin storan, seperti di atas Seperti yang ditunjukkan dalam rajah:

  Kemas kini data dengan id=10 dalam jadual pengguna Jika tiada data sedemikian dalam kumpulan penimbal, anda mesti mendapatkan semula data asal daripada data yang dikemas kini daripada cakera Data dimuatkan ke dalam kumpulan penimbal.
  • Pada masa yang sama, untuk memastikan keselamatan data yang dikemas kini secara serentak, data ini akan dikunci terlebih dahulu untuk menghalang transaksi lain daripada dikemas kini.

  • Kemudian sandarkan nilai sebelum mengemas kini dan tuliskannya ke dalam log buat asal (untuk memudahkan mendapatkan semula data lama apabila urus niaga digulung semula Sebagai contoh, penyata kemas kini menyimpan nilai sebelum ini). medan yang dikemas kini.

  • Kemas kini data cache dalam kumpulan penimbal kepada data terkini, maka data dalam memori pada masa ini adalah data kotor (data dalam memori dan data dalam cakera adalah tidak konsisten)

  ⾄Ini melengkapkan proses pelaksanaan dalam kumpulan penimbal (seperti yang ditunjukkan dalam gambar di atas).

  Selepas data dikemas kini dalam kumpulan penimbal, maklumat kemas kini perlu ditulis pada urutan Log Masuk Semula, kerana data dalam memori telah diubah suai, tetapi data pada cakera belum diubah suai . Pada masa ini, jika mesin di mana MySQL berada turun, data yang diubah suai dalam memori pasti akan hilang Log buat semula merekodkan pengubahsuaian yang telah anda buat pada data tersebut. id=10" row. Nilainya ialah xxx", ini ialah log, digunakan untuk memulihkan data anda yang dikemas kini apabila MySQL tiba-tiba ranap. Walau bagaimanapun, sila ambil perhatian bahawa Redo Log masih belum diletakkan dalam fail log pada masa ini.

  Fikirkan tentang soalan pada masa ini: Bagaimana jika MySQL hilang sebelum transaksi diserahkan?
  Kami tahu di atas bahawa kami telah mengubah suai data memori setakat ini, dan kemudian merekodkan Redo Log Buffer Jika MySQL ranap pada masa ini, data memori dan data Redo Log Buffer akan hilang, tetapi tidak penting jika data hilang pada masa ini , kerana kenyataan kemas kini tidak melakukan transaksi, yang bermaksud bahawa ia tidak berjaya dilaksanakan pada masa ini, semua data dalam memori telah hilang, tetapi anda akan dapati bahawa data pada cakera masih kekal seperti sedia ada.
  Langkah seterusnya adalah untuk melakukan transaksi Pada masa ini, log buat semula akan dipadamkan daripada penimbal log semula ke fail cakera mengikut strategi tertentu Pada masa ini, strategi ini dikonfigurasikan melalui innodb_flush_log_at_trx_commit .
  innodb_flush_log_at_trx_commit=0, yang bermaksud penyerahan transaksi tidak akan membuang data dalam penimbal log semula ke dalam fail cakera Pada masa ini, anda mungkin telah menyerahkan transaksi, dan akibatnya, mysql tidak berfungsi , dan kemudian data dalam ingatan akan Semua hilang, jadi pendekatan ini tidak digalakkan.
  innodb_flush_log_at_trx_commit=1, log buat semula dibuang dari memori ke fail cakera Selagi transaksi berjaya diserahkan, log buat semula mesti berada pada cakera, jadi jika MySQL ranap pada masa ini, anda. boleh mengikuti data Pulihkan Log Log Semula.
  innodb_flush_log_at_trx_commit=2, apabila melakukan transaksi, tulis log semula ke dalam cache os yang sepadan dengan fail cakera dan bukannya terus memasukkan fail cakera Data dalam cache os boleh ditulis selepas 1 saat fail cakera.
  Apabila transaksi diserahkan, binlog akan ditulis pada masa yang sama Binlog juga mempunyai strategi pembilasan yang berbeza Terdapat parameter sync_binlog yang boleh mengawal strategi pembilasan binlog masa, anda menulis binlog Apabila memasuki cakera, ia sebenarnya tidak memasuki fail cakera secara langsung, tetapi memasuki cache memori cache os. Secara amnya, untuk memastikan data tidak hilang, kami mengkonfigurasi strategi berganda 1 dan memilih 1 untuk kedua-dua strategi peletakan cakera Log Semula dan Binlog.

  Selepas Binlog diletakkan, nama fail Binlog, maklumat laluan fail dan tanda komit ditulis pada log Redo dalam urutan yang disegerakkan Kepentingan langkah ini adalah untuk memastikan log buat semula konsisten dengan log binlog. Tanda komit adalah kriteria penting untuk menentukan sama ada transaksi berjaya diserahkan Contohnya, jika MySQL ranap selepas langkah 5 atau langkah 6 berjaya dilaksanakan, kali ini kerana tiada tanda komit transaksi terakhir dalam log buat semula, jadi transaksi ini. boleh dinilai sebagai tidak berjaya. Ia tidak akan dikatakan bahawa terdapat log kemas kini ini dalam fail log buat semula, tetapi tiada log kemas kini ini dalam fail log binlog, jadi tidak akan ada masalah ketidakkonsistenan data.

  Selepas melengkapkan perkara di atas, data memori telah diubah suai, transaksi telah diserahkan, dan log telah diletakkan pada cakera, tetapi data cakera tidak diubah suai secara serentak. Terdapat benang IO di latar belakang enjin storan InnoDB Semasa tempoh puncak tekanan pangkalan data yang rendah, data dalam kumpulan penimbal yang telah dikemas kini melalui urus niaga tetapi belum sempat ditulis ke cakera (data kotor. , kerana data cakera dan data memori tidak lagi tersedia) konsisten) disiram ke cakera untuk melengkapkan kegigihan transaksi.

  Jadi proses penulisan InnoDB boleh diwakili oleh gambar berikut

  

  Pembelajaran yang disyorkan: tutorial video mysql
  

Atas ialah kandungan terperinci Penjelasan terperinci tentang seni bina mysql yang menarik dan pengetahuan enjin storan InnoDB. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!