MySQL バッファー プールの変更バッファーの導入

#4 バッファ変更

4.1 基本概念

バッファ変更は、セカンダリ インデックス ページがバッファ プールにない場合に、そのページへの変更をキャッシュする特別なデータ構造です。 INSERT、UPDATE、または DELETE 操作 (DML) によって発生する可能性のあるバッファーの変更は、後で他の

read 操作 によってページがバッファー プールに読み込まれるときにマージされます。

関連する無料学習の推奨事項:

mysql ビデオ チュートリアル

上の図からわかるように、変更バッファが使用されます。 バッファ プール内のメモリは無限に増加することはできません。変更バッファのサイズは、パラメータ innodb_change_buffer_max_size を通じて動的に設定できます。

たとえば、50 に設定すると、変更バッファのサイズはバッファ プールの最大 50% までしか占有することができません。

データ ページを更新する必要がある場合:

ページがメモリ内にある場合は、影響を与えることなく、メモリ内にない
• ページを直接更新します。データの整合性、InooDB これらの更新操作は、ディスクからページを読み取る必要がなく、変更バッファーにキャッシュされます。

次のクエリがデータ ページにアクセスすると、データ ページが読み込まれます。メモリにアクセスし、このページに関連する操作で変更バッファが実行されます。このようにして、データロジックの正確性を保証できます。

変更バッファは実際には永続データです。つまり、メモリにコピーされるだけでなく、ディスクにも書き込まれます。

4.2 マージ

変更バッファ内の操作を元のデータ ページに適用して最新の結果を取得するプロセス。

4.2.1 トリガーのタイミング

データ ページへのアクセス
1. システム バックグラウンド スレッドは定期的にマージされます
2. データベースは正常終了 (シャットダウン) プロセス

#更新操作を最初に変更バッファーに記録してディスク読み取りを減らすことができれば、ステートメントの実行速度が大幅に向上します。また、データをメモリに読み取るにはバッファ プールを占有する必要があるため、メモリ使用量が削減され、メモリ使用率も向上します。

4.3 変更バッファを使用する場合

一意のインデックスの場合、更新操作はまず、操作が一意性制約に違反するかどうかを判断する必要があります。
• たとえば、 , (4,400) レコードを挿入するには、まず k=4 レコードが既にテーブルに格納されているかどうかを確認し、データ ページをメモリに読み込んで確認する必要があります。すべてがメモリに読み込まれている場合、メモリを直接更新するのは非常に高速であり、変更バッファを使用する必要はありません。
  したがって、一意のインデックスの更新には変更バッファを使用できません。
  通常のインデックスのみが使用できます。

4.4 該当するシナリオ

通常のインデックス作成のすべてのシナリオは、変更バッファーを使用することで高速化できますか?

マージはデータが実際に更新されるときであり、変更バッファーは主に記録された変更アクションをキャッシュすることに注意してください。したがって、データ ページがマージされる前に、変更バッファ レコードの変更が多いほど (つまり、データ ページを更新する必要がある回数が多いほど) メリットは大きくなります。

ビジネスでは、より多くの書き込みを行い、より少ない読み取りを実現します。書き込み直後にページにアクセスされる可能性は低いため、変更バッファーの使用が最も効果的です。一般的に使用されるのは、請求システムとログ システムです。

• 書き込み直後のクエリでは、新しいレコードは最初に変更バッファに記録されますが、その後すぐにデータ ページにアクセスされ、すぐにマージがトリガーされます。この場合、ランダム アクセスの数はIO は削減されませんが、変更バッファのメンテナンス コストが増加します。変更バッファには副作用があります。

#その他の関連する無料学習の推奨事項:

mysql チュートリアル(ビデオ)

以上がMySQL バッファー プールの変更バッファーの導入の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。