2011-11-10 32 views
3

これは私が勝つ!同じクエリ、異なるDB、同じDB構造、同じDBサーバー、異なる実行計画

お客様のクライアントには、2つのDB、1つのテスト、1つのプロダクションを持つ1つのSQL Serverインスタンスがあります。どちらのDBも同じですが、テーブル構造、インデックスなどです。特定のクエリ(以下の構造)がテストDB上で実行されると、30秒以内に行が返されます。プロダクションDBでは、行が戻るまでに1.5時間かかる!!アクティビティモニタには、待機タイプなしで実行中のクエリが表示されます。すべての統計情報は最新です。実行計画を比較すると、主な違いはネストされた(プロード)対ハッシュジョイン(テスト)です。本番DBには、パフォーマンスを向上させるためのインデックスを追加することができますが、テストサーバーとほぼ同じ実行時間を受け取りますが、テストサーバーにはこの追加のインデックスは必要ありません。

クライアントは技術的ではなく、したがってビューに参加するビューを使用していません。この問題自体はパフォーマンスに関して解決されます(本番DBに追加のインデックスを追加することにより)。しかし、テストDBが追加の索引なしで検索を実行する理由はまだ解決できません。

誰でも光を当てることはできますか?私たちは困惑している!

クエリ構造:

SELECT field1, 
     field2, 
     field3, 
     DATEDIFF(mi, field5, field5) as 'Time' 
    FROM MainView t 
    JOIN SecondaryView i ON t.NonIndexedColumn = i.NonIndexedColumn 
WHERE date >= '2010/07/05' 
    AND date < '2011/09/27' 
    AND anotherDate IS NULL 
    AND Code LIKE 'Abc%' 
    AND Desc LIKE('%ABC%') 
+0

? –

+0

データ量はどうですか?どのくらいのデータがあなたのテスト環境にありますか?あなたが生産のデータのわずか5~10%を持っている場合、コースの実行は大きく異なるでしょう... –

+0

同じ行数、同じソースシステムから抽出された同じデータ:( – DarzzyDarzz

答えて

-1

それが原因でディスクまたは「テーブルの断片化」に関するさまざまなデータ分布の可能性があります。 データは

INSERT INTO test.table 
SELECT * FROM prod.table 

ステートメントを使用して、例えば、輸入された場合には、テスト・データベース内のデータは、生産と同じくらいのスペースを持っていません。しかし、これはデータが生産でどのように扱われているかによって異なります。

チェックsys.dm_db_index_physical_stats機能のperfmon統計についてのクエリが実行されている間は何

+0

フラグメンテーションはchoicに影響しません実行計画のe。 –

関連する問題