2012-02-14 8 views
0

データベースに2つのテーブルがあります。以下は注文を使用するとSQL Server Join Queryが遅くなる

  1. U_Accounts(行を含む小さなテーブル)
  2. SMS_Buffer(SMSキューを含む大きなテーブル)

我々はORDER BYを使用する場合

Select SMS_Buffer.msg_id, 
     SMS_Buffer.u_id, 
     SMS_Buffer.msgtxt, 
     SMS_Buffer.m_priority, 
     U_Accounts.U_Priority 
From SMS_Buffer 
JOIN U_Accounts ON Sms_Buffer.u_id = U_Accounts.u_id 
where U_Accounts.u_msgpush=1 
Order by U_Accounts.u_priority DESC, 
     SMS_Buffer.m_priority DESC, 
     SMS_Buffer.m_id DESC 

クエリ上記のサンプルクエリが遅くなるです文節がSMS_Buffer.m_priority DESC, SMS_Buffer.m_id DESCで、レコードが100000行未満の場合はSMS_Buffer表それが成長すると、クエリは非常に遅くなります。

上記のクエリのパフォーマンスを向上させるソリューションを提供してください。

クラスタ化された非クラスタ化インデックスを作成しようとしましたが、成功しませんでした。

+1

次回にコードをフォーマットしてください。 – Blorgbeard

+2

作成したインデックスと実行計画は何ですか? – HLGEM

+1

ゆっくりと定義してください... –

答えて

1

索引や理想的な実行計画についての情報がなければ、これは正しく答えることはできませんが、行数が比較的少ない高速問合せでは、特定のボリュームに達するとパフォーマンスが急速に低下します通常、フルテーブルスキャンを使用するクエリを表します。これは、テーブルがメモリに収まるときに悪くはないが、データが大きくなり、ディスクにデータが書き込まれるときに壊滅的に悪化します(ディスクI/Oは操作のオーダあなたがこれを打つポイントはしばしば目立つ)。

これに対処する唯一の方法は、実行計画を調べて、完全スキャンの原因を特定することですが、この盲目を解決しようとしている重要な情報はありません。

+0

あなたの最善の策は、実行計画を参照することです - それは最高になるでしょう - [リンク](http://www.simple-talk.com/sql/performance/execution-plan-基本/) – Aklopper

0

私が同じ種類のものに遭遇したとき、フライの答えはthis questionから助けられました。短い更新統計は解決策かもしれません。 SQLの場合EXEC sp_updatestats

私は2つのサブクエリとテーブルを扱っていましたが、ソートしていました。 3つの結果セットは5,000行未満で、Order Byを追加すると12秒から5分になります。それはばかげて遅かった。統計を更新した後、1秒で実行されました。

関連する問題