SQL Server 2005でテーブル全体を処理するインデックススキャンの前にソート

Question

SQL Server 2005データベースのパフォーマンスの発注に問題があります。このクエリは、7行を返すと実行に約23秒かかります

select 
    id, versionId, orderIndex 
from Forms_Page 
where 
    versionId = 'AFCF4921-31B4-44C1-B3A7-913910F7600E' 
order by 
    orderIndex 

： は、私は次のクエリを考えてみましょう。

select（コスト：0％）→ソート（コスト：11％）→クラスタインデックススキャン（コスト：89％）このクエリの実行計画は次のとおりです（画像をまだ投稿できません）

'order by'句を削除した場合、クエリは予想どおり〜4ミリ秒で完了します。

要求された行を取得する前にSQL Serverがソートを実行するのはなぜですか？それは私には意味がありません。なぜ7行を最初に取得し、それらをソートしないのですか？私はデータベース構成のような何かを見逃していますか？これは予期された動作ですか？

私は、以下のような内部選択を使用して、エンジンに最初に行を取得させてから、6ms後に行を返すように強制することができましたが、EFを使用しているので、 （私たちはメモリ内の結果をソートすることができましたが、ソート付きのSQLコードを生成するエンティティのいくつかにLoadWithオプションを使用しています。また、そのコードは同じ 'order by'問題を抱えています）。私はいくつかのインデックス作成をテストしている

select * 
from(
    select 
     id, versionId, orderIndex 
    from Forms_Page 
    where 
     versionId = 'AFCF4921-31B4-44C1-B3A7-913910F7600E' 
) T 
order by 
    T.orderIndex 

はなく、列がすでにソートされているという理由だけで、事を固定ソート列です。クールなソリューションのようです...

Answer 1

まず、私はなぜそれをやっているのかわかりません！それを言って、ここにあなたがすでに試した可能性があるいくつかのことがあります。

• クエリヒント： はあなたがここに文書化され、様々なクエリヒントのいずれかを使用してみましたか？ http://msdn.microsoft.com/en-us/library/ms181714.aspx。特にRECOMPILEオプション。

• DBCC FREEPROCCACHEとDBCC DROPCLEANBUFFERSの通常の手順はどうですか？これらは私が通常試みるものです。

• 統計情報の更新：データベース全体の統計情報を更新するには、UPDATE STATISTICS tablenameまたはEXEC sp_updatestatsを実行してください。

最後に、そしておそらくあなたのケースでは、関連するが、テーブルの良い説明がありますいないここにヒント：http://blog.sqlauthority.com/2009/11/19/sql-server-understanding-table-hints-with-examples/