検索最適化テーブルの使用¶

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

テーブルの変更¶

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

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

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

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

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

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

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

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

テーブル、スキーマまたはデータベースをクローンすると、各テーブルの SEARCH OPTIMIZATION プロパティと検索アクセスパスもクローンされます。（テーブル、スキーマ、またはデータベースをクローニングすると、各テーブルとそれに対応する検索アクセスパスのゼロコピークローンが作成される。）

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

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

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

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

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

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

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

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