MERGE tempdb kullanıyor mu?

Aşağıdaki sorguyu düşünün:

MERGE [Parameter] with (rowlock) AS target
    USING (SELECT @AreaId, @ParameterTypeId, @Value)
            AS source (AreaId, ParameterTypeId, Value)
    ON (target.AreaId = source.AreaId AND 
        target.ParameterTypeId = source.ParameterTypeId)
    WHEN MATCHED THEN 
        UPDATE SET target.Value = source.Value, @UpdatedId = target.Id
    WHEN NOT MATCHED THEN
        INSERT ([AreaId], [ParameterTypeId], [Value])
        VALUES (source.AreaId, source.ParameterTypeId, source.Value);

İstatistik G / Ç aşağıdaki çıktıyı verir:

Tablo 'ParameterType'. Tarama sayısı 0, mantıksal okuma 2, fiziksel okuma 0, okuma öncesi okuma 0, lob mantıksal okuma 0, lob fiziksel okuma 0, lob okuma öncesinde 0 okuma
. Tablo 'Alan'. Tarama sayısı 0, mantıksal okuma 2, fiziksel okuma 0, okuma öncesi okuma 0, lob mantıksal okuma 0, lob fiziksel okuma 0, lob okuma öncesinde 0 okuma
. Tablo 'Parametre'. Tarama sayısı 1, mantıksal okumalar 4, fiziksel okumalar 0, ileri okumalar 0, lob mantıksal okumalar 0, lob fiziksel okumalar 0, lob okuma öncesi okumalar 0
Tablo 'Çalışma masası'. Tarama sayısı 1, mantıksal okuma 0, fiziksel okuma 0, okuma öncesi okuma 0, lob mantıksal okuma 0, lob fiziksel okuma 0, lob okuma öncesinde okuma 0.

Worktable, mesajlar sekmesinde görünür ve bu da bana tempdb tarafından kullanıldığını düşündürür MERGE.

Yürütme planında tempdb'ye ihtiyaç olduğunu belirten hiçbir şey görmüyorum

Her MERGEzaman tempdb kullanıyor mu?

BOL'de bu davranışı açıklayan bir şey var mı?

Bu durumda kullanmak INSERTve UPDATEdaha hızlı olur mu?

Ayrıldı

Sağ

İşte masa yapısı

^{(Soru hakkındaki yorumumu genişletiyorum.)}

Kombinasyonuna benzersiz kısıtlama olmadan AreaIdve ParameterTypeIdçünkü, verilen kod kırılır @UpdatedId = target.Iddaima yalnızca bir satır kaydeder Id.

Bunu siz söylemezseniz, SQL Server verilerin olası durumlarını dolaylı olarak bilemez. Kısıtlama uygulanmalı veya birden çok satır geçerliyse , Iddeğerlerin çıktısını almak için farklı bir mekanizma kullanmak için kodun değiştirilmesi gerekir .

Tarama operatörünün birden fazla eşleşen satıra rastlama olasılığı nedeniyle, sorgunun Cadılar Bayramı koruması için tüm maçları biriktirmesi gerekir. Yorumlarda belirtildiği gibi, kısıt olan SQL Server ya 0 olacak orada biliyor ya edecektir olarak ekleyerek sadece bir sağlama yönünde gerekli tarama planı değiştirmek değil, aynı zamanda masa makara ihtiyacını ortadan kaldırmaz böylece, geçerli Arama satırından 1 satır döndürüldü.

Güncelleştirme, güncelleştirme tarafından taranan dizindeki satırın konumunu değiştirebilirse, SQL Server'ın Cadılar Bayramı Sorunu'ndan korunması gerekir . Bunun için SQL Server genellikle dizin taramasından hemen sonra yürütme planına istekli bir tablo biriktirme ekler. Bu operatör temel olarak söz konusu satırların bir kopyasını oluşturur ve bunun için tempdb kullanır.

MERGE ifadesinin güncelleme bölümü aynı kurallara uymak zorundadır ve ayrıca Cadılar Bayramı Korumasının gerekli olduğu çoğu durumda bir tablo makarası kullanır.

Ben dizin tanım (lar) bilmiyorum gibi, sorgunuzda bu durumda olup olmadığını söyleyemem, bu büyük olasılıkla burada oluyor budur.