インデックス作成などの基本はすべてまったく同じ方法で機能するため、厳密に言えば、違いを犯すことのコストだけが違います。
とはいえ、ここに、覚えておく価値のある（必ずしも完全ではない）リストを示します。
- Bツリーインデックスには追加のレベルが含まれている可能性が高いため、Bツリーインデックスの使用コストはわずかに高くなります。ただし、DWではビットマップインデックスを使用する必要があります（エンタープライズ版を持っている場合）
- テーブル全体の統計情報を計算するには、通常の夜間ウィンドウでは実行できない場合があるまで、さらに時間がかかります。これは克服することができます
estimate_percent統計を収集するときに小さい値を使用すると、サンプリングされるテーブルが少なくなります。- 増分統計収集の使用（ただし、パーティション化されたテーブルにグローバルインデックスがある場合にのみ該当）
- インデックスのヒストグラムは254バケットに制限されています。行が多いほど、値がより明確になることを意味します。つまり、「ほとんど使用されていない」値は、偏ったデータの大きな問題になる可能性があります。
- テーブル全体がバッファキャッシュに収まる可能性はゼロに近づきます。つまり、より多くの物理（ディスク）読み取りを行う可能性が高くなります。通常のワーキングセットも、キャッシュするには大きすぎる場合があります。
- パーティショニングはあなたの友達になることができます-あなたがそれを正しく理解すれば！通常、複数のパーティションにわたってデータを変更してクエリを実行している場合、プレーンテーブルよりもコストがかかる可能性があります。
- マテリアライズドビューは、作業セットを減らすのに非常に役立ちます。たとえば、10年以上のデータがあり、ユーザークエリの大部分が過去2年間に反対している場合、このデータだけに制限されたMVを作成すると大きな助けになります。
- データベースが大きいほど、ビジネスがライブ環境の完全な複製であるテストデータベースに資金を提供する可能性が低くなります。クエリが遅いのはデータの規模や物理的なストレージが原因である可能性があるため、テストでパフォーマンスの問題を再現するのが難しくなります。はるかに小さなテストDBから対応するライブパフォーマンスまで、クエリ結果を推定できるとは限りません。
実行プランを読んで理解するのにまだ慣れていない場合は、これらを学習するのに少し時間を費やします。ある時点でパフォーマンスの問題にぶつかる可能性があるため、問題を正しく診断する方法を知ることは、新しいものを追加することが難しいため、より重要になります。行数が多い場合は、インデックスを作成するか、スキーマを変更します。