57

このクエリに出くわしたとき、私はいくつかのSQLを整理していました:

SELECT 
        jm.IMEI ,
        jm.MaxSpeedKM ,
        jm.MaxAccel ,
        jm.MaxDeccel ,
        jm.JourneyMaxLeft ,
        jm.JourneyMaxRight ,
        jm.DistanceKM ,
        jm.IdleTimeSeconds ,
        jm.WebUserJourneyId ,
        jm.lifetime_odo_metres ,
        jm.[Descriptor]
FROM    dbo.Reporting_WebUsers AS wu WITH (NOLOCK)
        INNER JOIN dbo.Reporting_JourneyMaster90 AS jm WITH (NOLOCK) ON wu.WebUsersId = jm.WebUsersId
        INNER JOIN dbo.Reporting_Journeys AS j WITH (NOLOCK) ON jm.WebUserJourneyId = j.WebUserJourneyId
WHERE   ( wu.isActive = 1 )
        AND ( j.JourneyDuration > 2 )
        AND ( j.JourneyDuration < 1000 )
        AND ( j.JourneyDistance > 0 )

私の質問は、上記のクエリの場合と同様に、結合の順序によってパフォーマンスに違いが生じるかどうかです。

FROM dbo.Reporting_JourneyMaster90 AS jm

そして、他の2つのテーブルをそのテーブルに結合しました

4

6 に答える 6

41

いいえ、最適化中に順序による JOIN が変更されます。

唯一の注意点は、結合を指定した正確な順序で強制的に実行するオプションFORCE ORDERです。

于 2013-05-03T14:18:35.950 に答える
12

パフォーマンスに影響を与える内部結合の明確な例があります。これは、2 つのテーブル間の単純な結合です。1 つには 5,000 万以上のレコードがあり、もう 1 つのレコードには 2,000 があります。小さいテーブルから選択して大きいテーブルに参加すると、5 分以上かかります。

大きなテーブルから選択して小さなテーブルに参加すると、2 分 30 秒かかります。

これは SQL Server 2012 の場合です。

最初のクエリに最大のデータセットを使用しているため、これは直感に反します。

于 2014-11-15T16:48:46.247 に答える
7

通常はありません。私は 100% ではありませんが、これは Sql-Server に逐語的に適用されますが、Postgres では、クエリ プランナーは適切と思われる内部結合を並べ替える権利を留保します。例外は、注文の変更を調査するにはコストがかかりすぎるしきい値に達した場合です。

于 2013-05-03T14:14:31.207 に答える
7

JOIN順序は問題ではありません。クエリ エンジンは、インデックスやその他の統計に基づいて順序を再編成します。

テストのために、次のことを行います。

  • 実際の実行計画を表示し、最初のクエリを実行するを選択します
  • 順序を変更JOINして、クエリを再度実行します
  • 実行計画を比較する

クエリ エンジンは他の要因に従ってそれらを再編成するため、それらは同一である必要があります。

他の回答者にコメントしたOPTION (FORCE ORDER)ように、必要な順序を正確に使用するために使用できますが、最も効率的な順序ではない可能性があります。

一般的な経験則として、JOIN の順序は、最少レコードのテーブルを一番上にし、ほとんどのレコードを最後にする必要があります。一部の DBMS エンジンでは順序によって違いが生じる可能性があるため、FORCE ORDER コマンドを使用して結果を制限した場合と同様です。 .

于 2013-05-03T14:27:42.753 に答える