1

ID を主キーとして写真情報を格納するテーブルがあります。

id(PK)、タイトル、アルバム ID、投稿者、公開済み、ファイル名、タグ、評価、投稿日

このテーブルには 1 億枚以上の写真の情報が保持されるため、次のようなクエリを頻繁に実行する必要があります。

1) 特定のアルバムのすべての写真 (ID、ファイル名、タイトル列のみ) を取得する

Album_id = @AlbumId および published = 1 の写真から ID、ファイル名、タイトルを選択します

2) 特定のユーザーの公開されたすべての写真を取得しますが、現在表示中のアルバムの写真は除外します

posted_by='bob' and album_id <>10 and published = 1 の写真から ID、ファイル名、タイトルを選択

インデックスとテーブルのスキャンを避けたい。可能な限りシーク（たとえば100％）を使用する必要があります。

これはできますか？これを達成するのに役立つのは、どのタイプのインデックスとどの列ですか?

ありがとう

4

4 に答える 4

2

実際には、微調整する前にパフォーマンスを測定し、次に微調整を繰り返して測定することによってのみ、自分でこれを見つけることができます。

ただし、クエリに基づいて、次のような非クラスター化インデックスを検討する (または少なくともこれを最初に試す) 必要があります。

CREATE NONCLUSTERED INDEX IX01_Photos
  ON dbo.Photos(album_id, published, posted_by)
  INCLUDE(id, filename, title)

理由:

  • 最も頻繁に使用するクエリの両方にalbum_idandを使用する WHERE 句がpublishedあるため、インデックスで最初にこれら 2 つの列を使用します。
  • 2番目のクエリにもposted_byWHERE句が含まれています-それを3番目の列と同じインデックスに入れます
  • 実際のデータ テーブルへの高価なブックマーク ルックアップを避けるためid, filename, titleに、インデックスに列を含めることができます。

これらすべてが整っていると、クエリを満たすために、その新しい非クラスター化インデックスでインデックス シークがほとんど見られるはずです。しかし、繰り返しになりますが、質問で言及していない可能性があり、自分自身についても考えていない可能性がある他の多くの要因も関係していますが、このアプローチは良い出発点になるはずです。

于 2010-07-23T21:47:34.813 に答える
0

Id の主キー。非クラスタ化します。これはあまり使われないと思います (特に、すべての検索がアルバムまたはポスターによるものである場合)。

AlbumId のクラスター化インデックス。ほとんどのクエリで使用されるようです。

Posted_By の非クラスター化インデックス。クラスター化されたインデックスである AlbumId を使用すると、このインデックスのリーフ レベルに表示されるため、INCLUDEd 列のように機能します。使用状況によっては、これをクラスター化インデックスとして使用する方が良い場合があります...しかし、varchar(20) として使用すると、より多くのディスク領域が必要になり、パフォーマンスは AlbumId よりも悪くなります (AlbumId が int であると仮定)。

ビット列には索引付けできないため、Published を索引内の列として持つことはできません。また、1 億行以上の行で可能な値が 2 つしかない場合、SQL がクエリの最適化に使用することはおそらくないでしょう。

Posted_By を正規化することをお勧めします (独自のテーブルに移動し、独自の代理キーを与え、それをこのテーブルの外部キーとして使用します)。これにより、メイン テーブルのストレージ スペースが大幅に削減され、全体的なパフォーマンスが向上し、必要に応じてクラスター化インデックスをその列に切り替えることができます。(また、"Bob" がテーブルに投稿し、次に町の反対側の "Bob" も投稿した場合、Bob と Bob をどのように区別しますか?)

于 2010-07-23T22:21:12.410 に答える
0

date_posted または id をクエリのフィルター条件として使用する必要があるかどうかについて言及していないため、時系列以外の列で CLUSTERED インデックスを使用するのが最善かもしれません (現在の CLUSTERED インデックスはPKですよね？）。

album_id に CLUSTERED インデックスを作成します。

CLUSTERED インデックスを変更できない場合、または既存のクラスター化インデックスの恩恵を受ける他の多くのクエリがある場合は、@marc_s からの回答をサポートします (それに応じて投票します)。

于 2010-07-23T21:52:56.753 に答える
0

前者が最もヒットする場合は、上のクラスター化インデックスalbum_idと上のセカンダリ インデックスをお勧めします。が最もヒットposted_byした場合、それらを反転します。またはposted_byそれぞれにある写真の数によっては、呼び出しコードでフィルター処理することが非常に現実的な場合があります (つまり、クエリで制限として追加せず、クライアント側でフィルター処理します)。そうでない場合は、その発行された制約をクエリに追加する必要がありますが、主な制限は、小さなスキャンのみが発生することを意味する必要があります。ただし、前述のように、クライアント側でフィルタリングする方が簡単な場合があります。album_idposted_bypublishedalbum_idpublishedpublished

于 2010-07-23T22:04:12.140 に答える