1

これは私の心をおびえさせ、あと3日間はテストできないので、尋ねた方がいいかもしれません...

次のような標準の JOIN ステートメントがあるとします。

SELECT 
  names.name
  ,adresses.adress
FROM
  names
JOIN
  adresses
ON
  names.ID=adresses.FK_ID

データベース エンジン/オプティマイザにこれを高速に実行させたいとします。

質問：違いは何ですか

  • クエリ実行時間
  • メモリ使用量
  • ランタイムを改善する利用可能な SQL Server ソフトウェア テクノロジ

これらの場合に該当する場合:

  1. 2 つのテーブルが同じデータベース内にある
  2. 2 つのテーブルは、同じインスタンスの 2 つの異なるデータベースにあります。
  3. テーブル「names」は私のインスタンスにあり、テーブル「addresses」はリンクされたデータベース（サーバーオブジェクト）にあります

ケース 1 の場合、そのようなクエリ ランタイムを強化するための私の通常の戦略 (不要なデータ/重複を消去し、必要に応じてデータ型の長さを削減する以外) は、適切なインデックスと統計を構築することです。

ケース 2 でそうすると、オプティマイザはケース 1 と同じようにインデックスと統計を利用できるでしょうか? クエリプランは似ていますか? 実行時間とメモリ使用量は似ていますか? （私はほぼ100％確信しています。これも読んだことがあります：2つの異なるデータベースの2つのテーブル間の結合の問題は何ですか？）

ケース 3 の場合、明らかに時間のかかるネットワーク トラフィックとプロトコル スタッフ/ハンドシェイクが関係します。私のインスタンスは、最初に「アドレス」の完全な結果セットを RAM/スワップにロードしてから、JOIN を実行しますか? または、リンクされたサーバーに「ねえ、これらの ID を調べて、結果のアドレスを返してください!」と伝えるのが賢明でしょうか? ? (リンクされたデータベースの「アドレス」に FK_ID のインデックスがあるとします)

「住所」が私のインスタンスにあり、「名前」がリンクされたインスタンスにあり、追加するとします

WHERE names.name='John Smith'

クエリに対して、インスタンスは「名前」の完全なセットをロードし、そのヒープで一致する ID をスキャンしてから、「アドレス」でインデックス シークを実行しますか? または、リンクされたデータベースに「この名前に一致する ID を見つけてくれませんか?」と尋ねることもできますか? (繰り返しますが、ID のインデックスが存在すると仮定します) そして、その「アドレス」に移動しますか?

基本的に私は、そのオプティマイザが実際にどれほど賢いか (私は知っています: 私よりも賢いです^^)、そして 2 つのオプティマイザがスマートな方法で協力して、融合したクエリ プランまたは何かを考え出すことができるかどうかを知りたいです。基礎の段階。

この問題は、おそらく何度も対処/回答/ブログされています。ポインタ/リンク/回答/トリック/回避策をありがとう...

4

1 に答える 1

2

簡単な答え（質問の長さを考えると、少し罪悪感を覚えます）は、オプティマイザーはサーバー上にある情報を非常に認識している（したがって、ケース1とケース2は同じ計画を持つ必要があります）が、それほどスマートではないということです向こうの情報について。リンクされたサーバー (server.database.schema.table など) に対して JOIN を実行すると、おそらくテーブル スキャンが発生することになります。

于 2013-10-05T02:05:08.467 に答える