複数のインデックスを持つSQLクエリ-SQL Server 2000

indexing sql sql-server-2000 sql-server-2005
複数のインデックスを持つSQLクエリ-SQL Server 2000

私はこのような同様のクエリを使用します

select.....from.. with... (INDEX=IX_TABLE_1, INDEX=IX_TABLE_2)...

以下のエラーが出ます

_
テーブルごとに許可されるインデックスヒントのリストは1つのみです
_

これはSQL Server 2005でうまく機能しているようです。 SQLサーバーの問題ですか?

  0  0


ベストアンサー

私はあなたが使用している構文のせいかもしれません。

(INDEX = IX_TABLE_1、INDEX = IX_TABLE_2)の代わりに、次を試してください:

(INDEX=IX_TABLE_1, IX_TABLE_2)

2つの「INDEX =」パーツがあるという事実だと思います。

また、クエリオプティマイザーは通常、使用する最適なプラン/インデックスを選択する必要があるため、最後の手段としてインデックスヒントを使用することをお勧めします。 一般的に、オプティマイザーを信頼する必要があるのはこのためです。 インデックスヒントを使用する場合、時間とともに悪化する可能性があるため、かなり頻繁に確認することをお勧めします(例: データ量が増加するにつれて、元々ヒントでパフォーマンスが向上したものが、パフォーマンスが低下し始める可能性があります)。

3


実際には、そもそもインデックスヒントを与えるべきではありません。

説明

  1. SQL言語の背後にある目的の1つは、
    「方法」から「何」。 言い換えると;クエリは、データアクセスパスではなく、必要な結果セットのルールを示す必要があります(これはまさにインデックスヒントの役割です)。

  2. クエリを特定のインデックスにバインドすると、次のことができなくなります
    より良いインデックスを追加することにより、パフォーマンスが向上します。 I.e. また、クエリを変更する必要があります。

  3. ヒントオプションの多くはプラットフォーム固有です。移植性が低下する
    あなたがそれらを使用するとき。

  4. クエリオプティマイザーは、すべてのインデックス、さまざまな
    シナリオに参加し、最も重要なこと。テーブル内のデータに関する統計情報。 これらすべてのベースを自分でカバーし、今日使用する理想的なインデックスを決定できたとしても、 6か月後には、データベース内の特定の値、レコード、参照の統計的頻度が変更された可能性があり、インデックスの選択が適切でなくなった可能性があります。

サイドノート

オプティマイザーが使用するインデックスについて愚かな選択をしているように見える場合;これは一般にさらなる調査を必要とします。

  • 最初のステップとして。テーブルの統計は合理的に最新のものですか?

  • 第二に、オプティマイザーが特定のものを拒否していないことを確認してください
    インデックスは、実際にはインデックス* reduces *のパフォーマンスを示しているためです。 たとえば、次のいずれかを実行したい場合があります。+

SELECT  Col1, Col2, Col3, ...
FROM    Customers WITH (INDEX=IndexByName)
WHERE   FistName LIKE 'A%'

SELECT  Col1, Col2, Col3, ...
FROM    Customers WITH (INDEX=IndexByName)
ORDER BY FirstName

インデックスヒントは完全に論理的に見えます。しかしながら:

  • インデックスがクラスター化されている場合、またはカバーリングインデックスの場合:使用されます
    とにかく-ヒントなし。

  • インデックスがクラスタ化されておらず、カバーしていない場合:ブックマーク検索は
    取得した各レコードに必要です。 これにより、多大なオーバーヘッドが発生します。特にディスクシークアクティビティで。 したがって、結局のところ、インデックスは適切な選択ではありません。

最後に

それが本当かどうかはわかりません。しかし、あなたの質問は、それが複雑なマルチテーブルクエリであることを示すものではありません。 実際、次のように些細なことかもしれません。

SELECT  Col1, Col2, ...
FROM    ATable WITH (INDEX=Index1, INDEX=Index2)

状況がどうであれ、単一のテーブルに対して複数のインデックスを_ヒント_することは意味がありません(自己結合で複数回使用されない限り)。 あなたが言った:

_
これはSQL Server 2005でうまく機能しているようです。
_

そして私は尋ねなければなりません:本当にですか? +試しました。エラーメッセージが発生しない限り、オプティマイザーを真剣に混乱させました。 オプティマイザーが同じテーブルを2回(* unnecessarily *)トラバースし、結果セットを相互に結合するように強制しました-多大なオーバーヘッドが発生しました!!

-1


タイトルとURLをコピーしました