MySQL 8.0 リファレンスマニュアル


17.5.1.27 レプリケーションおよび行検索

行ベースのレプリケーション形式を使用するレプリカが UPDATE または DELETE 操作を適用する場合、関連するテーブルで一致する行を検索する必要があります。 このプロセスの実行に使用されるアルゴリズムでは、いずれかのテーブルインデックスを使用して最初の選択として検索を実行し、適切なインデックスがない場合はハッシュテーブルを使用します。

アルゴリズムは、まずテーブル定義で使用可能なインデックスを評価して、使用する適切なインデックスがあるかどうか、および複数の可能性があるかどうかを確認します。どのインデックスが操作に最適ですか。 このアルゴリズムは、次のタイプのインデックスを無視します:

  • 全文インデックス。

  • 非表示インデックス。

  • 生成されたインデックス。

  • Multi-valued indexes.

  • 行イベントのビフォアイメージにインデックスのすべてのカラムが含まれていないインデックス。

これらのインデックスタイプを除外した後に適切なインデックスがない場合、アルゴリズムは検索にインデックスを使用しません。 適切なインデックスがある場合は、次の優先順位で候補から 1 つのインデックスが選択されます:

  1. 主キー。

  2. インデックス内のすべてのカラムに NOT NULL 属性がある一意のインデックス。 このようなインデックスが複数使用可能な場合、アルゴリズムはこれらのインデックスの左端を選択します。

  3. その他のインデックス。 このようなインデックスが複数使用可能な場合、アルゴリズムはこれらのインデックスの左端を選択します。

インデックス内のすべてのカラムに NOT NULL 属性がある主キーまたは一意インデックスをアルゴリズムで選択できる場合、このインデックスを使用して UPDATE または DELETE 操作の行を反復処理します。 行イベントの各行について、アルゴリズムはインデックス内の行を検索して、更新するテーブルレコードを検索します。 一致するレコードが見つからない場合は、エラー ER_KEY_NOT_FOUND が返され、レプリケーションアプライヤスレッドが停止します。

アルゴリズムが適切なインデックスを見つけられなかった場合、または一意でないか NULL を含んでいたインデックスのみを見つけることができた場合は、ハッシュテーブルを使用してテーブルレコードを識別します。 このアルゴリズムは、UPDATE または DELETE 操作の行を含むハッシュテーブルを作成し、そのキーを行の完全なビフォアイメージとして使用します。 アルゴリズムは、検出された場合は選択されたインデックスを使用してターゲットテーブルのすべてのレコードを反復処理し、それ以外の場合は全テーブルスキャンを実行します。 ターゲットテーブルのレコードごとに、その行がハッシュテーブルに存在するかどうかが判別されます。 ハッシュテーブルで行が見つかった場合、ターゲットテーブルのレコードが更新され、ハッシュテーブルから行が削除されます。 ターゲットテーブルのすべてのレコードがチェックされると、このアルゴリズムはハッシュテーブルが空であるかどうかを検証します。 ハッシュテーブルに一致しない行が残っている場合、アルゴリズムはエラー ER_KEY_NOT_FOUND を返し、レプリケーションアプライヤスレッドを停止します。

slave_rows_search_algorithms システム変数は、以前は一致する行の検索方法を制御するために使用されていました。 前述のように、インデックススキャンの後にハッシュスキャンを使用するデフォルト設定はパフォーマンスに最適であり、すべてのシナリオで正しく機能するため、このシステム変数の使用は非推奨になりました。


関連キーワード:  インデックス, テーブル, アルゴリズム, ソース, ベース, バイナリ, GTID, 変数, 検索, トランザクション