2

同僚から、クエリの実行時間が非常に長いため、いくつかのテーブルのインデックス作成を調べるように依頼されました。1時間以上。

select count(1)
from databaseA.dbo.table1
inner join databaseA.dbo.table2 on (table1.key = table2.key)
inner join databaseB.dbo.table3 on (table1.key = table3.key)

異なるデータベースに注意してください。これは DatabaseB から実行されていました

テーブル 1 と 2 は、200 万を超えるレコード長でした。Table3 には 10 ほどのレコードがありました。

クエリ プランを調べたところ、オプティマイザは、Table3 を駆動テーブルとして、テーブル 1 と 2 へのネスト ループ インデックス シークを実行することにしました。

私の最初の仮定は、Tables1 と 2 で統計がひどく台無しになっているということでしたが、統計を更新する前に、次のように結合ヒントを追加しようとしました。

select count(1)
from databaseA.dbo.table1
inner HASH join databaseA.dbo.table2 on (table1.key = table2.key)
inner join databaseB.dbo.table3 on (table1.key = table3.key)

結果は 15 秒で返されました。

時間がなかったので、結果を彼に返しましたが、これが後で問題になるのではないかと心配しています.

統計の問題を再検討して、その方法で問題を解決する必要がありますか? 別のデータベースからの結合が原因で、不適切なクエリ プランが発生した可能性はありますか?

あなたの経験に基づいて誰かが私にいくつかのアイデアを提供できますか?

4

4 に答える 4

2

まず統計を疑います。

ご存じのとおり、Join ヒントは 99% のケースで回避し、絶対に必要であるという証拠がある場合にのみ使用する必要があります。

于 2008-12-31T01:59:24.503 に答える
1

ネストされたループが最も適切ではないでしょうか? 表 3 の 12 レコードを取得すると、表 1 の 12 レコードと一致し、表 2 の 12 レコードと一致します。

そうしないと、ハッシュ結合によって順序付けも強制されます。つまり、表 1 と表 2 から 100 万件のレコードをハッシュしてから、表 3 の 12 レコードに結合します。

両方の計画の統計を調べます。ループ結合は実際にはより効率的ですが、ブロックされているか、ハッシュ結合がキャッシュされたデータを利用していると思われます。

しかし、ええ、一般的に、結合ヒントは最後の手段です。

于 2008-12-31T03:17:30.507 に答える
1

リンク サーバーを含む実行速度の遅いクエリは、照合に関係している可能性があります。背景については、こちらを参照してください: http://blogs.msdn.com/psssql/archive/2008/02/14/how-it-works-linked-servers-and-collat ​​ion-compatibility.aspx 、それでパフォーマンスの向上が説明されます。

オプションの設定方法は次のとおりです。

EXEC master.dbo.sp_serveroption 
    @server=N'databaseA', 
    @optname=N'collation compatible', 
    @optvalue=N'true'

EXEC master.dbo.sp_serveroption 
    @server=N'databaseA', 
    @optname=N'use remote collation', 
    @optvalue=N'false'

-エドード

于 2009-01-21T15:01:20.640 に答える
1

最初に統計とテーブルのインデックスを確認してください。インデックス ヒントは問題を引き起こす可能性があります。テーブル内のデータが変更された場合、常にハッシュを使用するように強制されているため、オプティマイザーはより効率的な計画を選択できなくなります。

于 2008-12-31T02:21:30.620 に答える