MySQL InnoDB ストレージエンジンのメモリ管理の詳細な説明

MySQL InnoDB ストレージエンジンのメモリ管理の詳細な説明

ストレージエンジンのメモリ管理

InnoDB ストレージ エンジンでは、データベース内のバッファー プールは LRU (Latest Recent Used) アルゴリズムによって管理されます。つまり、最も頻繁に使用されるページは LRU リストの先頭に配置され、最も使用頻度の低いページは LRU リストの末尾に配置されます。バッファー プールが新しく読み取られたページを格納できない場合は、LRU リストの末尾にあるページが最初に解放されます。

上の図では、キューを表すために 8 つのデータ ページを使用しています。それぞれの具体的な機能については、後ほど説明します。 InnoDB ストレージ エンジンでは、バッファー プール内のページのデフォルト サイズは 16 KB です。LRU リストには中間点の位置があります。新しく読み取られたデータ ページは、LRU リストの先頭に直接配置されるのではなく、LRU リストの中間点の位置に配置されます。この操作は、中間点挿入戦略とも呼ばれ、中間点挿入戦略とも呼ばれます。デフォルト構成では、この位置は LRU 長さの 5/8 にあるため、上記では 8 つのデータ ページが使用されます。次の図は、新しいデータ ページを挿入するプロセスを示しています。

mitpoint の場所は、次のようにパラメータ innodb_old_blocks_pct によって制御できます。

mysql> 'innodb_old_blocks_pct' のような変数を表示します。
+-----------------------+-------+
| 変数名 | 値 |
+-----------------------+-------+
| innodb_old_blocks_pct | 37 |
+-----------------------+-------+
 セット内の行 (. sec)

上記の例から、結果は 37 となり、新しく読み取られたページは LRU リストの末尾の約 37% の位置に挿入されることを意味します。これは距離の約 3/8 です。InnoDB ストレージ エンジンでは、中間点より前のページを新しいリスト、中間点より後のページを古いリストと呼びます。新しいリストのページは、最もアクティブなデータです。

データ ページを LRU キューの先頭に置かないのはなぜですか?

新しく読み取られたデータ ページが LRU キューの先頭に配置されない理由は、一部のフル テーブル スキャン SQL 操作によって LRU キューからすべてのホット データが更新され、ホット データへの次のアクセスで対応するデータをディスクから取得する必要が生じ、バッファー プールの効率に影響が出るためです。この問題を解決するために、InnoDB は別のパラメータ innodb_old_blocks_time を使用して LRU リストを管理します。このパラメータは、ページが中間点まで読み取られた後、LRU リストのホット エンドに追加されるまでにかかる時間を示すために使用されます。したがって、上記のような SQL 操作を実行する必要がある場合、次の方法を使用することで、LRU リスト内のホット データがフラッシュアウトされることをできるだけ防ぐことができます。

mysql> グローバル innodb_old_blocks_time= を設定します。
クエリは正常、行は影響を受けました (0.00 秒)

つまり、1000 秒後には、データを LRU リストのホット エンドに更新できるようになります。

実際の状況では、データ ページのアクティブ率が 63% を超える場合、ユーザーは innodb_old_blocks_pct を設定することで、ホット ページがフラッシュされる可能性を減らすこともできます。

mysql> グローバル innodb_old_blocks_pct= を設定します。                                                                                                     
クエリは正常、行は影響を受けました (0.00 秒)

データベースを起動したばかりのときは、LRU の内容は空です。このとき、すべてのデータ ページは Free リストに配置されます。バッファー プールからのページングが必要な場合は、まず Free リストから使用可能な Free ページがあるかどうかを確認します。ある場合は、Free ページからページを削除してから、LRU リストに配置します。 LRU リストの末尾にあるデータ ページを削除し、新しいページにメモリ領域を割り当てます。このプロセスのフローチャートは次のとおりです。

LRU リスト内のページが古い部分から新しい部分に追加されるとき、このときに発生する操作は page made young と呼ばれ、innodb_old_blocks_time の設定により古い部分から新しい部分に移動されない操作は page_not_made young と呼ばれます。 show engine innodb status を使用して、LRU リストと空きリストの使用状況と実行状態を確認できます。

mysql> エンジン innodb ステータスを表示\G
***
***
----------------------
バッファプールとメモリ
----------------------
割り当てられた大容量メモリの合計 
辞書メモリ割り当て 
バッファプールのサイズ   
空きバッファ       
データベースページ     
古いデータベースページ 
変更されたDBページ  
保留中の読み取り      
保留中の書き込み: LRU、フラッシュリスト、単一ページ 
若くないページ 
0.00 ヤング/秒、0.00 非ヤング/秒
読んだページ、作成したページ、書き込んだページ 
0.00 読み取り/秒、0.00 作成/秒、0.00 書き込み/秒
最後の印刷以降、バッファプールページは取得されません
ページ先読み 0.00/秒、アクセスなしで削除 0.00/秒、ランダム先読み 0.00/秒
LRU 長さ: 、unzip_LRU 長さ: 
I/O sum[]:cur[]、unzip sum[]:cur[]
--------------
行操作
--------------
 InnoDB 内のクエリ、キュー内のクエリ
 InnoDB 内で開かれたビューの読み取り
プロセス ID=、メイン スレッド ID=、状態: スリープ
挿入、更新、削除、読み取りされた行数 
0.00 挿入/秒、0.00 更新/秒、0.00 削除/秒、0.00 読み取り/秒
----------------------------
INNODB モニター出力の終了
============================

 セット内の行数 (0.00 秒)

上記の結果から、現在のバッファ プール サイズは合計 8191 ページであり、各データ ページのサイズは 16k、バッファ プールの合計サイズは 8191*16k=128M であることがわかります。ここで、Free buffers は現在の Free リスト内のページ数を示します。 page made young は、LRU リスト内のページが先頭に移動された回数を示します。サーバーは操作中に innodb_old_blocks_time の値を変更しないため、not young は 0 です。youngs/s と non_youngs/s は、1 秒あたりのこれら 2 種類の操作の数を示します。

InnoDB ストレージ エンジンはバージョン 1.0.x 以降で圧縮ページをサポートしており、元の 16 KB のデータ ページを 1 KB、2 KB、4 KB、8 KB に圧縮します。 16KB以外のページはunzip_LRUで管理されます。上記コマンドの22行目には圧縮ページと非圧縮ページの情報が表示されています。

注意すべき点の 1 つは、空きバッファー値とデータベース ページ値の合計が必ずしもバッファー プール サイズと等しくならないことです。これは、バッファー プール内のページには、アダプティブ ハッシュ インデックスやロック情報などのページも割り当てられる可能性があり、これらのページでは LRU アルゴリズムのメンテナンスが必要ないためです。

ダーティページ

LRU リスト内のページが変更された後、そのページは「ダーティ ページ」と呼ばれます。つまり、バッファ プール内のデータ ページはディスク上のデータと一致しません。バッファ プール内のデータの方が新しいです。このとき、データベースはチェックポイント メカニズムを通じてダーティ ページをディスクにリフレッシュし、フラッシュ リスト内のページはダーティ ページ リストになります。ダーティ ページは、LRU リストとフラッシュ リストの両方に存在します。LRU リストは、バッファ プール内のページの可用性を管理するために使用され、フラッシュ リストは、ディスクへのページのリフレッシュを管理するために使用されます。この 2 つは互いに影響しません。フラッシュ リストは、show engine innodb status を通じても表示できます。前の結果リストの 13 行目にある modified db pages は、現在のダーティ ページの数であり、メタデータ テーブル INNODB_BUFFER_PAGE_LRU を通じて表示できます。

以上がMySQL InnoDBストレージエンジンのメモリ管理の詳細な説明です。InnoDBのメモリ管理の詳細については、123WORDPRESS.COMの他の関連記事に注目してください。

以下もご興味があるかもしれません:
  • MySQLアーキテクチャに基づく分析
  • MySQLアーキテクチャに基づく詳細な分析
  • MySQLのストレージエンジンの詳細な説明
  • MySQLメモリストレージエンジンに関する知識
  • MySQL のストレージ エンジンの違いと比較
  • MySQL シリーズ 7 MySQL ストレージ エンジン
  • MySQLのInnoDBストレージエンジンにおけるさまざまなロックの詳細な説明
  • MySQL の MyISAM ストレージ エンジンにおける非クラスター化インデックスの詳細な説明
  • MySQL ストレージ エンジン InnoDB と MyISAM
  • MySQL アーキテクチャとストレージ エンジンの紹介

<<:  JS での new の手書き実装

>>:  ウェブページのアクセス速度に関する主な問題と解決策

推薦する

MySQL 上級学習インデックスの長所と短所、使用ルール

1. インデックスの利点と欠点利点: 高速検索、高速グループ化および並べ替えデメリット: ストレージ...

アイデアのパッケージ化とクラウドサービスへのアップロードにおけるプロジェクトプロセスの分析

1つ。まず、アイデアとしてパッケージ化する必要があります。私はSpringbootフレームワークプロ...

コンパイル、インストールから設定ファイルの説明まで、中国語でnginxの詳細な説明

この記事では、コンパイルとインストールから設定ファイルの説明まで、Nginx について詳しく紹介しま...

node-media-serverを使用してシンプルなストリーミングメディアサーバーを構築する

node-media-server を使用するプロセスの一部を記録します。この記事の環境はWindo...

MySql8.0.19 インストールピットレコードを共有する

前回の記事ではMySql8.0.19のインストール手順を紹介しました。必要な方はクリックしてご覧くだ...

Vue は携帯電話の認証コードによるログインを実装します

この記事では、携帯電話認証コードログインを実装するためのVueの具体的なコードを参考までに共有します...

Ubuntu 18.04で国内ソースを変更する方法の例

Ubuntu はソースが中国からなのでダウンロード速度が比較的遅いです。CentOS と異なり、yu...

全画面ページのスクロール効果を実現するJavaScript

JavaScript DOM を読み終えた後、解釈型 JavaScript スクリプト言語に対する...

フィルターと固定間の競合の原因と解決策の詳細な説明

問題の説明body内でfilter属性を使用すると、 fixed要素の位置が不正確になります。つまり...

VMware Workstation Pro が Windows で実行されない場合の解決策

国慶節の休暇後、Windows アップデート後に VMware 仮想マシンが開けなくなり、「VMwa...

JS WebSocket 切断理由とハートビートの仕組みの詳しい説明

1. 切断理由WebSocket が切断される理由は多数あります。WebSocket が切断されたと...

ラムダ式の原則と例

ラムダ式ラムダ式 (クロージャとも呼ばれる) は、Java 8 のリリースを推進した最も重要な新機能...

Ubuntu 19でdockerソースをインストールできない問題を共有する

主要な Web サイトと個人的な習慣に従って、Docker ソースを追加するには次の方法を使用します...

ウェブページにコンテンツが多すぎる場合に、下から上へ素早く戻る方法

Web フロントエンド開発では、ページに多くの記事を表示することが避けられません。記事の最後にあるク...

React Routerの歴史について簡単に説明します

React Router を理解したいなら、まず歴史を理解する必要があります。より具体的には、Rea...