1

ストアド プロシージャに出くわしましたが、これにはいくつかの障害がありました。1つは、開発者がこれを行ったことです。

SELECT alias.firstname, alias.surname, alias.id
FROM
    (SELECT firstname, surname, id, address, anotherfield, etc, etc
     FROM TableName
     WHERE afield = avalue) alias

したがって、これは明らかに次と同じです。

SELECT firstname, surname, id
     FROM TableName
     WHERE afield = avalue

これが何度も繰り返されました。私の質問は、サブクエリを実行することでパフォーマンスが低下することはありますか? 私はそれが役に立たないことを知っています...そして最善のアイデアはそれを正しくすることです-私はそうしました。しかし、そのままにしておくことでパフォーマンスが低下することはありますか?

クエリオプティマイザーはそれを理解して正しいことをすると思いますか?

4

3 に答える 3

2

このような単純なケースでは、SQLServerはこれらのクエリを同じ実行プランに折りたたみます。

私はAdventureWorks2012でこれを試しました：

SELECT CarrierTrackingNumber, ProductID, UnitPrice, LineTotal
FROM 
(
  SELECT *
    FROM Sales.SalesOrderDetail
    WHERE ProductID = 781
) AS Alias;

SELECT CarrierTrackingNumber, ProductID, UnitPrice, LineTotal
FROM Sales.SalesOrderDetail
     WHERE ProductID = 781;

計画は同一であり、実行時メトリックの違いは区別できません。

ここに画像の説明を入力してください

また、複雑なタイプ（地理）のテーブルを意図的に選択して、次のことも試しました。

 SELECT AddressLine1, City, StateProvinceID 
 FROM Person.Address
   WHERE StateProvinceID = 9;

 SELECT AddressLine1, City, StateProvinceID 
 FROM 
 (
   SELECT * FROM Person.Address
   WHERE StateProvinceID = 9
 ) AS x;

 SELECT AddressLine1, City, StateProvinceID 
 FROM 
 (
   SELECT * FROM Person.Address
 ) AS x
 WHERE StateProvinceID = 9;

同じことですが、いずれの場合も、オプティマイザはインデックススキャンに折りたたまれ、参照されているように見える他の列を無視します。

ここに画像の説明を入力してください

これと同じ最適化を信頼して、より複雑なクエリで実行できるかどうかはわかりません。オプティマイザーは常に完全または予測可能であるとは限りません...したがって、この崩壊が確実に発生しない、より複雑なクエリを確実に想像することができます。

あなたが見ているパターンの価値を理解しているかどうかはわかりません。おそらく、実際に何らかの目的を果たす例がそこにあります。

于 2013-03-06T00:58:53.733 に答える
2

プロジェクションのみが外側のクエリに含まれる場合、2 つのクエリ間で実行計画に違いはまったくないはずです。内部クエリと外部クエリの両方に「where」句を含むより複雑なクエリは、クエリ オプティマイザーの制限をテストし、2 レベルのクエリに対して劣ったクエリ プランを生成する可能性がありますが、あなたの場合、プランと実行速度は同一。

于 2013-03-06T00:45:12.423 に答える
1

2 つのクエリの実行計画は、パフォーマンスの点では同じです。オプティマイザーは、未使用の列を単に破棄します。

于 2013-03-06T00:38:34.480 に答える