0

ここで非常に頻繁に使用される Crystal Report を最適化しようとしています。多くのクエリを最適化することに成功しましたが、最後のボトルネックが 1 つあります。これは、レポートから生成されたメイン クエリです。

SELECT
    A.*,
    B.*,
    C.*,
    D.*,
    E."N",
    F."N",
    G."N"
FROM
    A
LEFT OUTER JOIN B ON
    A."PK" = B."FK"
LEFT OUTER JOIN C ON
    A."PK" = C."FK"
LEFT OUTER JOIN D ON
    A."FK" = D."PK"
LEFT OUTER JOIN E ON
    A."PK" = E."FK"
LEFT OUTER JOIN F ON
    A."PK" = F."FK"
LEFT OUTER JOIN G ON
    A."PK" = G."FK"
WHERE A.PK = ####

A、B、C、D はテーブルです。E、F、G は単純なビューです。

ご覧のとおり、レポートは複数の LEFT JOINS を生成しました。このクエリが完了するまでに 2.28 秒かかります (Plan Viewer 統計より)。問題と思われる結合を 3 つ特定しました。クエリから E、F、G を削除すると、ほぼ瞬時になります (同じ統計から 0.0009 秒)。

SELECT
    A.*,
    B.*,
    C.*,
    D.*
FROM
    A
LEFT OUTER JOIN B ON
    A."PK" = B."FK"
LEFT OUTER JOIN C ON
    A."PK" = C."FK"
LEFT OUTER JOIN D ON
    A."FK" = D."PK"
WHERE A.PK = ####

ビューが遅いのかもしれないと思いましたが、たとえばそうすると...

SELECT *
FROM E
WHERE E.FK = ####

... それもほぼ瞬時 (0.0009 秒)

すべてのテーブルには、PK-FK のインデックスがあります。ビュー E、F、G はすべて、列として [FK|N] を含む行を 1 つ返すか、まったく返さないため、結果の列は NULL または数値になります。

このクエリを高速化する方法を知っていますか?

PS: LEFT OUTER JOINS を INNER JOINS に置き換えると、メインクエリが高速になります... :-/

または、このクエリをレポートで複数のクエリに分割しようとする方が良い解決策でしょうか?

ありがとうございました！

4

2 に答える 2

0

E、F、G を結合するのではなく、それらを検索する関数を作成します。そうすれば、オプティマイザーが混乱して愚かなことをしようとする可能性はほとんどなくなります。

SELECT
    A.*,
    B.*,
    C.*,
    D.*,
    GET_E(A."PK"),
    GET_F(A."PK"),
    GET_G(A."PK")
FROM
    A
LEFT OUTER JOIN B ON
    A."PK" = B."FK"
LEFT OUTER JOIN C ON
    A."PK" = C."FK"
LEFT OUTER JOIN D ON
    A."FK" = D."PK"
WHERE A.PK = ####
于 2012-11-13T15:56:09.917 に答える
0

問題はおそらくA、何らかの方法ですべて結合された 5 つのテーブルの巨大なデカルト積を作成しているためです (AそしてD、積に 1 つのレコードのみを提供します)。このような大きなデカルト積を持つと、Sybase の内部で大量のメモリが消費されます。クエリが間違っている可能性があります。

于 2012-11-13T15:48:17.223 に答える