13

ストアド プロシージャ内に一時テーブルを作成していて、それに 1 つまたは 2 つのインデックスを追加して、それに対して作成された追加ステートメントのパフォーマンスを向上させたい場合、最善の方法は何ですか? Sybase は次のように述べています。

「インデックスを作成するとき、テーブルにはデータが含まれている必要があります。一時テーブルを作成し、空のテーブルにインデックスを作成する場合、Adaptive Server はヒストグラムや密度などのカラム統計を作成しません。インデックスの作成後にデータ ローを挿入すると、オプティマイザの統計が不完全です。」

しかし最近、同僚が、一時テーブルを実際に使用するストアド プロシージャとは別のストアド プロシージャで一時テーブルとインデックスを作成すると、Adaptive Server オプティマイザがそれらを利用できると言いました。

全体として、私はほとんど付加価値のないラッパー手順の大ファンではないので、実際にこれをテストすることはできませんでしたが、誰かが他に何か持っているかどうかを確認するために、そこに質問を出そうと思いました.アプローチやアドバイス？

4

3 に答える 3

7

いくつかの考え：

  • 一時テーブルが大きすぎてインデックスを作成する必要がある場合、問題を解決するためのより良い方法はありますか?

  • 次の形式のオプティマイザ ヒントを指定することで、(インデックスがテーブルにアクセスするための正しい方法であることが確実な場合) インデックスを使用するように強制できます。

    SELECT * 
FROM   #table (index idIndex) 
WHERE  id = @id

一般的なパフォーマンスのヒントに興味がある場合は、ここでそれに関する他のいくつかの質問にある程度答えています。

于 2008-09-30T15:53:12.073 に答える
3

一時テーブルにデータを入れた後にインデックスを追加する際の問題は何ですか?

留意する必要がある 1 つのことは、同時に実行されている可能性のあるプロシージャの他のインスタンスへのインデックスの可視性です。

私は、これらの種類の一時テーブル (およびインデックス) に GUID を追加して、競合が発生しないようにするのが好きです。このアプローチのもう 1 つの利点は、単純に一時テーブルを実際のテーブルにできることです。

また、ストアド プロシージャの実行中にこれらの一時テーブルのデータを複数回クエリする必要があることを確認してください。そうしないと、インデックス作成のコストが選択の利点を上回ります。

于 2008-09-10T11:45:09.317 に答える
1

Sybase では、一時テーブルを作成し、それを 1 つの proc で使用する場合、テーブル内の推定 100 行を使用して選択の計画が作成されます。(プランは、テーブルにデータが入力される前に手順が開始されたときに作成されます。) これにより、一時テーブルが "100 行" しかないため、テーブル スキャンが行われる可能性があります。別の proc を呼び出すと、Sybase は実際の行数を使用して選択の計画を作成します。これにより、オプティマイザは使用するより適切なインデックスを選択できます。このアプローチを使用して大幅な改善が見られましたが、違いがない場合があるため、データベースでテストしてください。

于 2008-09-15T20:29:42.413 に答える