A.16.1. |
セカンダリインデックスを変更してバッファリングを変更する操作のタイプは何ですか。
|
|
INSERT 、UPDATE および DELETE 操作では、セカンダリインデックスを変更できます。 影響を受けるインデックスページがバッファプールにない場合、変更は変更バッファにバッファできます。
|
A.16.2. |
InnoDB 変更バッファにはどのようなメリットがありますか。
|
|
セカンダリインデックスページがバッファプールにない場合にセカンダリインデックスの変更をバッファリングすると、影響を受けるインデックスページをディスクからすぐに読み取るために必要な負荷の高いランダムアクセス I/O 操作が回避されます。 バッファされた変更は、他の読取り操作によってバッファプールにページが読み取られるため、後でバッチで適用できます。
|
A.16.3. |
変更バッファは他のタイプのインデックスをサポートしていますか。
|
|
いいえ。変更バッファでは、セカンダリインデックスのみがサポートされます。 クラスタインデックス、全文インデックスおよび空間インデックスはサポートされていません。 全文インデックスには、独自のキャッシュメカニズムがあります。
|
A.16.4. |
InnoDB は変更バッファにどのくらいの領域を使用しますか。
|
|
MySQL 5.6 で innodb_change_buffer_max_size 構成オプションが導入される前は、システムテーブルスペースのディスク上の変更バッファの最大サイズは InnoDB バッファプールサイズの 1/3 でした。
MySQL 5.6 以降では、innodb_change_buffer_max_size 構成オプションによって、変更バッファの最大サイズがバッファプールの合計サイズに対する割合として定義されます。 デフォルトでは、innodb_change_buffer_max_size は 25 に設定されます。 最大設定は 50 です。
ディスク上の変更バッファが定義された制限を超える場合、InnoDB は操作をバッファしません。
変更バッファページは、バッファプールに永続化する必要はなく、LRU 操作によって削除される場合があります。
|
A.16.5. |
変更バッファの現在のサイズを確認するにはどうすればよいですか。
|
|
変更バッファの現在のサイズは、SHOW ENGINE INNODB STATUS \G によって INSERT BUFFER AND ADAPTIVE HASH INDEX ヘッダーの下にレポートされます。 例:
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
関連するデータポイントは次のとおりです:
変更バッファステータスの監視の詳細は、セクション15.5.2「変更バッファ」 を参照してください。
|
A.16.6. |
変更バッファのマージはいつ行われますか。
|
|
ページがバッファプールに読み込まれると、バッファされた変更は、ページが使用可能になる前に、読取りの完了時にマージされます。
変更バッファのマージはバックグラウンドタスクとして実行されます。 innodb_io_capacity パラメータは、変更バッファからのデータのマージなど、InnoDB バックグラウンドタスクによって実行される I/O アクティビティの上限を設定します。
クラッシュリカバリ中に変更バッファのマージが実行されます。 インデックスページがバッファプールに読み込まれると、変更は変更バッファ (システムテーブルスペース内) からセカンダリインデックスのリーフページに適用されます。
変更バッファは完全に永続的であり、システムクラッシュが発生する可能性があります。 再起動時に、変更バッファのマージ操作は通常の操作の一部として再開されます。
変更バッファの完全マージは、--innodb-fast-shutdown=0 を使用した低速なサーバー停止の一部として強制できます。
|
A.16.7. |
変更バッファはいつフラッシュされますか。
|
|
更新されたページは、バッファープールを占有するほかのページをフラッシュするのと同じフラッシュメカニズムによってフラッシュされます。
|
A.16.8. |
変更バッファはいつ使用しますか。
|
|
変更バッファは、インデックスが大きくなり、InnoDB バッファプールに収まらなくなったときに、ランダムな I/O をセカンダリインデックスに減らすように設計された機能です。 一般に、データセット全体がバッファプールに収まらない場合、セカンダリインデックスページを変更する大量の DML アクティビティがある場合、または DML アクティビティによって定期的に変更されるセカンダリインデックスが多数ある場合は、変更バッファを使用する必要があります。
|
A.16.9. |
変更バッファを使用しないのはいつですか。
|
|
データセット全体が InnoDB バッファープール内に収まる場合、比較的少ないセカンダリインデックスがある場合、またはソリッドステートストレージを使用している場合 (ランダム読み取りは順次読み取りとほぼ同じくらい高速)、変更バッファーを無効にすることを検討してください。 構成を変更する前に、代表的なワークロードを使用してテストを実行し、変更バッファを無効にすると利点があるかどうかを判断することをお薦めします。
|
A.16.10. |
変更バッファに関する追加情報はどこで入手できますか。
|
|
セクション15.5.2「変更バッファ」を参照してください。
|