AnalyticDB for MySQL では、デフォルトで全列にインデックスが作成され、データフィルタリングの高速化が図られます。ただし、一部のケースでは、インデックスによるフィルタリングがパフォーマンスを向上させるどころか、むしろ低下させることがあります。本ドキュメントでは、フィルター条件のプッシュダウンを無効化すべきタイミング、クエリ単位またはクラスター単位での適用方法、およびその適用状況の確認手順について説明します。
プッシュダウンの無効化は、あくまで特定の課題に対する一時的な回避策であり、適切なインデックス設計の代替にはなりません。以下に示すシナリオに継続的に該当する場合は、長期的な対応としてテーブルスキーマおよびインデックス戦略の見直しをご検討ください。
プッシュダウンを無効化するタイミング
以下のいずれかに該当する場合、フィルター条件のプッシュダウンを無効化してください。
低カーディナリティの列 — 列の値の種類（一意の値）が極めて少ないため、フィルタリングによって大量のデータが返されます。この場合、インデックスによる恩恵はほとんど得られません。
高いディスク I/O 負荷 — クエリ実行やデータ書き込みにより、既にディスク I/O が飽和状態にあります。インデックスによるフィルタリングは、同じディスク I/O リソースを競合し、全体のスループットを低下させます。
複数の複雑なプッシュダウン条件 —
LIKEや文字列比較などの操作を含む複数の条件が同時にプッシュダウンされると、ストレージノードで過剰なリソースが消費されます。
単一クエリに対してプッシュダウンを無効化
SQL ヒントを使用して、特定のクエリにおいて指定した列のフィルター条件プッシュダウンを無効化できます。このヒントは、対象のクエリにのみ適用され、クラスター全体には影響しません。
構文
構文は、クラスターのマイナーエンジンバージョンによって異なります。
バージョン 3.1.4 以降:
/*+ filter_not_pushdown_columns=[<schema1>.<table1>:<col1>|<col2>;<schema2>.<table2>:<col1>] */バージョン 3.1.4 より前:
/*+ no_index_columns=[<table1>.<col1>;<col2>,<table2>.<col1>] */区切り文字のリファレンス:
| 区切り文字 | 意味 | 例 |
|---|---|---|
: | テーブル名と列リストを区切る | table01:id|product |
| | 同一テーブル内の列を区切る | id|product |
; | 複数のテーブルエントリを区切る | test01.table01:id;test02.table03:key |
バージョン 3.1.4 以降では、データベース間のテーブルを参照する際に schema.table 形式を使用します。これにより、オプティマイザーが異なるデータベース内に存在する同名のテーブルを明確に識別できます。それより前のバージョンでは、クロスデータベースのヒントを使用する際、すべてのデータベースにわたってテーブル名が一意である必要があります。そうでない場合、意図せず他のテーブルにもヒントが適用される可能性があります。クラスターのマイナーエンジンバージョンを確認するには、「AnalyticDB for MySQL クラスターのバージョンを確認する方法」をご参照ください。バージョンをアップグレードするには、テクニカルサポートまでお問い合わせください。
使用例
1 つのテーブル内の 2 列に対してプッシュダウンを無効化（v3.1.4+）:
/*+ filter_not_pushdown_columns=[test01.table01:id|product] */id 列および product 列について、test01.table01 のフィルター条件プッシュダウンを無効化します。
2 つのデータベースにまたがるプッシュダウンの無効化（v3.1.4+）:
/*+ filter_not_pushdown_columns=[test01.table01:id|product;test02.table03:key] */id 列および product 列について test01.table01、および key 列について test02.table03 のフィルター条件プッシュダウンを無効化します。
バージョン 3.1.4 より前:
/*+ no_index_columns=[table02.id;product,table03.key] */id 列および product 列について table02、および key 列について table03 のフィルター条件プッシュダウンを無効化します。
ヒントが適用されたことを確認
ヒント付きクエリを実行した後、実行計画を確認してフィルター条件のプッシュダウンが無効化されていることを検証します。下記の「プッシュダウン状態の確認」を参照してください。
クラスター内のすべてのクエリに対してプッシュダウンを無効化
set adb_config 文を実行することで、クラスター内のすべてのクエリに対して特定の列のフィルター条件プッシュダウンを無効化できます。この設定は変更されるまで有効であり、個別のクエリヒントよりも優先されます。
構文
バージョン 3.1.4 以降:
set adb_config filter_not_pushdown_columns=[<schema1>.<table1>:<col1>|<col2>;<schema2>.<table2>:<col1>]バージョン 3.1.4 より前:
set adb_config no_index_columns=[<table1>.<col1>;<col2>,<table2>.<col1>]区切り文字の規則は、クエリレベルのヒントと同一です。上記の「区切り文字のリファレンス表」をご参照ください。
クロスデータベースの命名規則も同様に適用されます。バージョン 3.1.4 以降では schema.table 形式を使用してください。それより前のバージョンでは、すべてのデータベースにわたってテーブル名が一意であることを確認してください。クラスターのマイナーエンジンバージョンを確認するには、「AnalyticDB for MySQL クラスターのバージョンを確認する方法」をご参照ください。バージョンをアップグレードするには、テクニカルサポートまでお問い合わせください。
使用例
id 列について test02.table02 のプッシュダウンを無効化（v3.1.4+）:
set adb_config filter_not_pushdown_columns=[test02.table02:id]この設定は、id 列を参照する test02.table02 を含む、クラスター内のすべてのクエリに適用されます。
設定が適用されたことを確認
設定文を実行した後、代表的なクエリを実行し、その実行計画を確認して設定が有効になっていることを検証します。下記の「プッシュダウン状態の確認」を参照してください。
プッシュダウン状態の確認
実行計画を用いて、フィルター条件がプッシュダウンされているかどうかを判断します。
実行計画 タブで、TableScan オペレーターを含むステージをクリックします。
実行計画 タブへの移動手順については、「診断結果の表示」をご参照ください。
ステージ計画の表示 をクリックします。
ステージ計画ページで、TableScan オペレーターをクリックします。
右側の プロパティ セクションで、
PushedDownFilterプロパティを確認します。
現在 — フィルター条件がプッシュダウンされます。
存在しない場合 — フィルター条件がプッシュダウンされていません。
代替方法：Filter オペレーターによる確認
実行計画内で直接 Filter オペレーターを検索することでも、プッシュダウン状態を確認できます。
Elastic モードのクラスター — 実行計画の下流ステージに Filter オペレーターが表示される場合、関連するフィルター条件はプッシュダウンされていません。
Reserved モードのクラスター — 現在のステージ計画に Filter オペレーターが表示される場合、関連するフィルター条件はプッシュダウンされていません。