私は以下のSQLクエリを持っています、
SELECT TOP 5 C.CustomerID,C.CustomerName,C.CustomerSalary
FROM Customer C
WHERE C.CustomerSalary > 10000
ORDER BY C.CustomerSalary DESC
適当に説明すると以下の実行順序はどうなるか、
- TOP句
- WHERE句
- ORDER BY 句
私は以下のSQLクエリを持っています、
SELECT TOP 5 C.CustomerID,C.CustomerName,C.CustomerSalary
FROM Customer C
WHERE C.CustomerSalary > 10000
ORDER BY C.CustomerSalary DESC
適当に説明すると以下の実行順序はどうなるか、
TOP、WHERE、および ORDER BY は「実行」されません。これらは単に目的の結果を記述し、データベース クエリ オプティマイザーが実際の実行に最適なプランを (うまくいけば) 決定します。「目的の結果を宣言する」ことと、それを物理的に達成する方法を分離することが、SQL を「宣言型」言語にする理由です。
CustomerSalary
にインデックスがあり、テーブルがクラスター化されていないと仮定すると、次のSQL Fiddleに示されているように、クエリはインデックス シーク + テーブル ヒープ アクセスとして実行される可能性があります(下部にある[実行プランの表示] をクリックします)。
ご覧のとおり、最初にIndex SeekCustomerSalary
によって正しい値が検出され、次にRID Lookup (Row ID Lookup)によって値が属する行がテーブル ヒープから取得されます。Topはここに表示するためのものです (コストは 0% です)。ネストされたループも同様です。開始インデックス シークは、いずれの場合も (最大で) 1 行を返します。クエリ全体はかなり効率的で、おそらく数回の I/O 操作しかかかりません。
テーブルがクラスター化されている場合、このSQL Fiddleに示されているように、テーブル ヒープ アクセスの代わりに別のインデックス シークが必要になる可能性があります(DDL SQL に NONCLUSTERED キーワードがないことに注意してください)。
しかし、注意してください。今回は「正しい」実行計画を得ることができて幸運でした。クエリ オプティマイザーは、フル テーブル スキャンを選択した可能性があります。これは、小さなテーブルでは実際により高速な場合があります。クエリ プランを分析するときは、常に現実的な量のデータで分析するようにしてください。