0

現在、バックエンドが Teradata であるいくつかの bobj レポートを最適化しようとしています。Teradata オプティマイザは非常に扱いにくいようで、オプティマイザが likeを equals と同様に処理するようにするための解決策または回避策を誰かが思いついたのではないかと思っていました。

My issue is that we allow the user to input one of two methods:
 1. Enter the Number:
    or
 2. Enter a Number like:

オプション 1 は夢のように機能しますが、オプション 2 はクエリ時間を 6 秒から 2 分に引き延ばします。

それに加えて; Teradata オプティマイザーの SQL ステートメントの最適化に関する優れた記事、ディスカッション、ビデオなどを知っている人はいますか?

4

4 に答える 4

1

フルテキストインデックス/事前にトークン化されたインデックス（luceneなど）と、2つの解析検索が必要になります。

たとえば、データベースに「12345」を挿入する場合は、「1」、「12」、「123」、「234」などから「12345」へのリンクを作成します。

次に、「123 **」のようなものを検索する場合は、ルックアップテーブルから「123」を検索し、レコード「12345」をシークします。

于 2010-09-15T09:18:39.643 に答える
1

番号が索引付けされていると思いますか？Teradataはインデックス作成にハッシュを使用するため、equalsの場合はインデックスが使用され、likeの場合は全表スキャンになります。

likeを使用する必要がある場合は、できることはそれほど多くありません。試すことができることの1つは、Substr(Number, 1, 3) = '123'ではなくを使用することですNumber LIKE '123%'。私は過去にこれから小さなパフォーマンスの改善を得ましたが、素晴らしいものは何も期待していません。

于 2010-09-15T09:11:05.470 に答える
1

VARCHAR を直接比較する場合、つまり

Column LIKE 'VALUE'

次に、その列で NUSI の使用を試みることができます。テーブルのプライマリ インデックスとインデックスの統計を必ず収集してください。

于 2010-09-15T19:06:21.733 に答える
1

列は VARCHAR として定義されており、LIKE 演算子を使用しているため、単一の AMP アクセスに PI を使用する可能性を排除します。プライマリ インデックスの最初のジョブは、システム内の AMP 間でデータを分散していることを思い出してください。PI に対して LIKE 演算子を使用しているため、オプティマイザーは LIKE 演算子を満たすために「すべての AMP」操作を実行する必要があります。

WHERE MyPIColumn LIKE '123%'

123 で始まる値のハッシュは、複数の AMP になる可能性があります。

WHERE MyPIColum = '123'

123 のハッシュは、すべての単一レコードを同じ AMP に配置します。「123」のクエリは、常に単一の AMP 操作になります。

これに関する統計は、行の見積もりに役立つ場合がありますが、「すべての AMP」操作を排除することはできません。

  1. これは一意の PI ですか、それとも非一意の PI ですか?
  2. データ型が数値ではなく文字に選ばれたのはなぜですか? GT(E) または LT(E) は、同じ「オール AMP」操作になる可能性がありますが。
  3. この PI は、AMP ローカル結合戦略を促進するために、モデル内の他のテーブルと共有されていますか?
于 2010-09-30T16:20:53.893 に答える