テーブルを「遅くする」とは何でしょうか？

Question

テーブルを大幅に遅くするものは何でしょうか？おそらく最も簡単なだけで説明します

クエリ1：

select top 1000 * 
from call c 
JOIN call_task ct ON c.call_no=ct.call_no 
LEFT JOIN memo_clt m ON m.doc_ref=ct.record AND m.doc_type='CLT' AND m.line_no=1 
LEFT JOIN memo_clt m2 ON m2.doc_ref=ct.record AND m2.doc_type='CLT' AND m2.line_no=2 

クエリ2：

select top 1000 * 
from call c 
LEFT JOIN ext_document_detail edd ON edd.doc_type='CLH' 
              AND edd.doc_ext_no=21 
              AND edd.doc_ref=c.record 
LEFT JOIN ext_document_detail edSource ON edSource.doc_type='CLH' 
               AND edSource.doc_ext_no=22 
               AND edSource.doc_ref=c.record 

テーブルの構造が似ている、と私は非常によく似てext_document_detailにアクセスしています参加memo_cltテーブルと比較します。 2番目のクエリは40秒かかりますが、もう1つは0秒かかります。

どちらも、私が結合に使用している3つのキーにクラスタード・インデックスを持っています。 memo_cltテーブルは、レコードカラムにクラスター化されていないインデックスを持っています...それは私が見つけることができる唯一の違いであり、大きな違いはないと思います。

なぜここでスピードの違いがありますか？

EDITは：右二つのことが私を打っているバット

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'ext_document_detail'. Scan count 1001, logical reads 1507004, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'call'. Scan count 1, logical reads 24, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

：

Table 'memo_clt'. Scan count 2000, logical reads 6454, physical reads 0, read-ahead reads 0, lob logical reads 2385, lob physical reads 0, lob read-ahead reads 0. 
Table 'call_task'. Scan count 1, logical reads 39, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'call'. Scan count 1, logical reads 25, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

クエリ2：マーティンは尋ねたので、ここでは クエリ1 ON SET STATISTICS IOの結果です。まず、「Worktable」のような表がないことです。 2番目は論理的な読み込みの絶対数が非常に大きいです...何が原因でしょうか？

Answer 1

速度の違いを引き起こすのはテーブルそのものではありません。照会される表の結合およびサポート索引の構造です。

私はあなたの実行計画を見る必要があるスピードの違いのためのよい理由を与えるために。 1つのクエリで別のクエリよりも優れたインデックスが使用されていると思われます。

開始するには、テーブルスキャンがあるかどうかを確認するのがよいでしょう。これらを持っていて、最適化することができれば、パフォーマンスが向上する可能性があります。

私はthis articleをよく読んでいます。それは確かにチェックアウトし、理解する価値があります..