1

提案に従って、パフォーマンスを向上させるにはインデックスを最も選択的にする必要があります。一般的なガイドラインとして、テーブルの行の 15% 未満に対して頻繁に照会されるテーブルにインデックスを作成する必要がありますインデックス。

適切な選択性の例 100'000 レコードを含むテーブルで、そのインデックス付き列の 1 つに 88000 の個別の値がある場合、このインデックスの選択性は 88'000 / 10'0000 = 0.88 です。

今、ポイントに来てください。1,80,000 レコードを持つ 1 つのテーブルがあります。検索条件でよく使われるフィールドは、(1) ユーザー名による検索レコードです。フィールド タイプ :-> null 以外、nvarchar(32)。一意のレコードは、Active_date を使用した 627 (2) 検索レコードです。フィールド タイプ:-> DateTime、Null。一意のレコードは 85627 です。(3) Current_state フィールド タイプ :-> Not Null 、nvarchar(32) を使用してレコードを検索します。ユニークな記録は「保留中」と「クローズ済み」の2つだけです。

現在、上記のフィールドはすべて索引付けされています。選択性の面では、(1) と (3) は最も選択的ではありませんが、パフォーマンスを向上させるために何をすべきですか?

前もって感謝します、サム

4

1 に答える 1

0

選択性がすべてを物語るわけではありません。保留中のアプリケーションが 10 件あり、終了したアプリケーションが 1.000.000 件あるとします。次に、ステータスのインデックスはあまり選択的ではありませんが、それでも非常に便利です! インデックスは、人々が保留中のアプリケーションをすばやく参照するのに役立ちます。これは、頻繁に行うことかもしれません。

もう 1 つの例は、チケット システムです。ほとんどの作業はオープン チケットで行われます。そのため、チケットのステータスはあまり選択的ではありませんが、それでもインデックスの優れた候補です。

PS インデックスの最も左の既知の列のみを使用して検索を解決できます。例えば：

select * from Users where name = 'fred'

(name)このクエリを解決するためにon のインデックスを使用できますが、on のインデックスは使用(active_date, name)できません。

于 2013-09-11T11:44:47.867 に答える