検索最適化テーブルの操作¶

検索最適化は、一般的にユーザーに透明性があります。クエリは同様に機能します。高速になるものがあるだけです。しかし、他のテーブル操作が検索最適化サービスに及ぼす可能性のある影響、またはその逆の影響に注意することが重要です。

テーブルの変更¶

列のデフォルト値を変更すると、検索アクセスパスが無効になります。

検索アクセスパスが無効になった後に再度検索の最適化を使用するには、 SEARCH OPTIMIZATION プロパティをドロップし、テーブルに SEARCH OPTIMIZATION プロパティを追加しなおす必要があります。

列を追加、ドロップ、または名前変更した場合、検索アクセスパスは引き続き有効です。

特定の列を指定せずに、テーブル全体の検索最適化を有効にした場合、テーブルに列を追加すると、新しい列は検索アクセスパスに自動的に追加されます。ただし、列の検索最適化を有効にするときに ON 句を使用した場合、新しい列は自動的に追加されません。
テーブルから列をドロップすると、ドロップされた列は検索アクセスパスから自動的に削除されます。
列の名前を変更する場合、検索アクセスパスを変更する必要はありません。

テーブルをドロップすると、 SEARCH OPTIMIZATION プロパティと検索アクセスパスもドロップされます。次に注意してください。

テーブルのドロップを解除すると、テーブルのプロパティとして検索最適化がすぐに再確立されます。
テーブルをドロップすると、検索アクセスパスのデータ保持期間はテーブルと同じになります。

テーブルから SEARCH OPTIMIZATION プロパティをドロップすると、検索アクセスパスが削除されます。テーブルに再度 SEARCH OPTIMIZATION プロパティを追加する場合は、メンテナンスサービスのために検索アクセスパスを再作成する必要があります。（プロパティをアンドロップする方法なし。）

テーブル、スキーマ、またはデータベースのクローニング¶

テーブル、スキーマまたはデータベースをクローンすると、各テーブルの SEARCH OPTIMIZATION プロパティと検索アクセスパスもクローンされます。テーブル、スキーマ、またはデータベースをクローニングすると、各テーブルとそれに対応する検索アクセスパスのゼロコピークローンが作成されます。ただし、クローン作成時にテーブルの検索アクセスパスが古くなっている場合、検索アクセスパスを更新するために、検索最適化サービスのメンテナンスコストが元のテーブルとクローンテーブルの両方で発生します。

DML の操作によってクローン操作の直前にテーブルが大幅に変更された場合、検索アクセスパスが古くなる可能性があります。たとえば、 INSERT ステートメントによって元のテーブルのサイズが大幅に増加した場合、この変更を反映するために検索アクセスパスのメンテナンスが必要になります。

クローンされたテーブルでの検索最適化メンテナンスタスクのコストを回避または最小限に抑えるには、以下の手順のいずれかまたは両方を実行します。

クローンされたテーブルで検索最適化を有効にしたままにする必要がある場合は、 CREATE TABLE ... CLONE ステートメントを実行する前に、検索アクセスパスが最新であることを確認してください。そうでない場合は、次のステップに進んでください。

ほとんどの場合、 SHOW TABLES ステートメントを実行して、 SEARCH_OPTIMIZATION_PROGRESS 列の値を確認できます。列の値が 100 の場合、検索アクセスパスは最新です。ただし、削除されたソーステーブルデータに関連する情報を削除するために検索アクセスパスが圧縮されている場合は、メンテナンスが発生する可能性があります。
クローンが作成された直後に、クローンされたテーブルの検索最適化サービスを無効にします。たとえば、テーブル t1 の検索最適化サービスを無効にするには、以下のステートメントを実行します。
```
ALTER TABLE t1 DROP SEARCH OPTIMIZATION;
```
Copy
詳細については、 ALTER TABLE の検索最適化アクション（searchOptimizationAction）をご参照ください。

CREATE TABLE ... LIKE を使用して、元のテーブルと同じ列を持つ新しい空のテーブルを作成する場合、 SEARCH OPTIMIZATION プロパティは新しいテーブルにコピーされません。

セカンダリデータベースのテーブルの操作（データベース複製のサポート）¶

プライマリデータベースのテーブルで SEARCH OPTIMIZATION プロパティが有効になっている場合、プロパティはセカンダリデータベースの対応するテーブルに複製されます。

セカンダリデータベースの検索アクセスパスは複製されませんが、代わりに自動的に再構築されます。このプロセスには、検索最適化のコスト見積もりおよび管理で説明されているのと同じ種類のコストが発生することに注意してください。

マスキングポリシーおよび行アクセスポリシー¶

検索最適化サービスは、マスキングポリシーや行アクセスポリシーを使用するテーブルと完全に互換性があります。

ただし、検索最適化が有効になっている場合、マスキングポリシーまたは行アクセスポリシーのために値を表示できないユーザーは、その値が存在するかどうかをより確実に推測できる場合があります。検索最適化の有無にかかわらず、クエリの待機時間の違いから、ポリシーによって制限されたデータの有無に関するヒントが得られる可能性があり、データの機密性に応じてセキュリティ上の問題が発生する可能性があります。検索最適化は、結果を返さないクエリをさらに速くする可能性があるため、この影響はさらに大きくなります。

たとえば、行アクセスポリシーにより、ユーザーは country = 'US' を含む行にアクセスできませんが、データには country = 'US' を含む行が含まれていないとします。次に、 country 列に対して検索の最適化が有効になっており、ユーザーが WHERE country = 'US' でクエリを実行するとします。クエリは期待どおりに空の結果を返しますが、クエリは検索の最適化を使用しない場合よりも高速に実行される可能性があります。この場合、ユーザーは、クエリの実行にかかった時間に基づいて、データに country = 'US' の行が含まれていないとより簡単に推測できます。