コンポジットプライマリキーのスロー結合

Question

をStoreIDに結合するまで実行時間は〜2秒です。これは〜3分に増加します。ProductIDのみで結合すると〜2秒になります。

SELECT 
    Enabled = pp.PspEnabled 
    , StockStatusID = ss.ID 
    , WebSellable = pp.PspWebSellable 
    , CSSellable = pp.PspCsSellable 
FROM 
    #ExternalProducts pp 
JOIN 
    Product p ON p.ExternalCode = pp.code 
JOIN 
    Stores s ON s.Name = pp.p_externalStore 
JOIN 
    StockStatus ss ON ss.Name = pp.PspStockStatus 
JOIN 
    ProductStores ps ON (/* Store join increases time only */ ps.StoreID = s.ID AND ps.ProductID = p.ID) 

行：

• 店舗：108
• 製品：136'598
• ProductStores：609'963

キー：

CONSTRAINT [PK_dbo.Stores] 
    PRIMARY KEY CLUSTERED ([ID] ASC) 
CONSTRAINT [PK_dbo.Product] 
    PRIMARY KEY CLUSTERED ([ID] ASC) 
CONSTRAINT [PK_dbo.ProductStores] 
    PRIMARY KEY CLUSTERED ([ProductID] ASC, [StoreID] ASC) 

CONSTRAINT [FK_dbo.ProductStores_dbo.Stores_SiteID] 
    FOREIGN KEY([StoreID]) REFERENCES [dbo].[Stores] ([ID]) 
CONSTRAINT [FK_dbo.ProductStores_dbo.Product_ProductID] 
    FOREIGN KEY([ProductID]) REFERENCES [dbo].[Product] ([ID]) 

実行計画：

実行計画は、バルクコストがハッシュマッチから来ていることを示す（内部結合）ハッシュキープローブ[dbo].[Stores].Nameとハッシュキーと私は問題があると仮定した[#ExternalProducts].p_externalstoreを構築けどこれをどう解釈するのか分からないのですか？

すべてのヘルプは大歓迎です！

Answer 1

Denis Rubashkinは、実際の行番号と実際の行番号は実際には非常に異なることに注意しました。 UPDATE STATISTICSが実行計画の変更に失敗した後、私はProductStoresからフィルタを引っ張り、フィルタを#ExternalProductsから再構築しました。これにより、Nested Loop Join（より小さい結果セットの方が望ましいと思われます）を強制できました。

SELECT 
    Enabled = pp.PspEnabled 
    , StockStatusID = ss.ID 
    , WebSellable = pp.PspWebSellable 
    , CSSellable = pp.PspCsSellable 
FROM ProductStores ps 
JOIN Product p ON p.ID = ps.ProductID 
JOIN Stores s ON s.ID = ps.StoreID 
INNER LOOP JOIN #ExternalProducts pp ON (p.Code = pp.Code AND s.Name = pp.p_externalstore) 
JOIN StockStatus ss ON ss.Name = pp.PspStockStatus 

これは、この目的のために許容可能である〜3分〜7秒にクエリ時間を削減しました！