"Bazen" yavaş bir sorguyu teşhis etme konusunda öneriler

Bir kaplama dizini aracılığıyla dizinlenmiş bir görünümden sonuçları döndüren bir saklı yordam var. Genellikle hızlı çalışır (~ 10ms), bazen 8 saniyeye kadar çalışabilir.

Örnek bir rastgele yürütme (not: bu yavaş değil, ancak sorgu metni iletilen değerle aynıdır):

declare @p2 dbo.IdentityType
insert into @p2 values(5710955)
insert into @p2 values(5710896)
insert into @p2 values(5710678)
insert into @p2 values(5710871)
insert into @p2 values(5711103)
insert into @p2 values(6215197)
insert into @p2 values(5710780)

exec ListingSearch_ByLocationAndStatus @statusType=1,@locationIds=@p2

İşte SPROC:

ALTER PROCEDURE [dbo].[ListingSearch_ByLocationAndStatus]
    @LocationIds IdentityType READONLY,
    @StatusType TINYINT
AS
BEGIN
    SET NOCOUNT ON;

    SELECT      -- lots of fields
    FROM        [dbo].[ListingSearchView][a] WITH (NOEXPAND)
    INNER JOIN  @LocationIds [b] ON [a].[LocationId] = [b].[Id]
    WHERE       [a].[StatusType] = @statusType
    OPTION (RECOMPILE);

(not: OPTION (RECOMPILE)bazı tavsiyeler sonra son zamanlarda ipucu ekledim , ama yardımcı olmadı.

Kaplama dizini aşağıdadır (not: görünümün ListingIdbenzersiz bir kümelenmiş dizini vardır )

CREATE NONCLUSTERED INDEX [IX_ListingSearchView_ForAPI] ON [dbo].[ListingSearchView]
(
    [LocationId] ASC,
    [StatusType] ASC
)
INCLUDE ( -- all the fields in the query) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

Showplan XML istatistiği ile bir profil izleyici koydum.

İşte yavaş olanı (6 saniye) ve ilgili plan:

Tam olarak beklediğim gibi görünüyor ve sorgu hızlı olduğunda aynı plan.

İşte yardımcı olursa, planın maliyetli kısmını yakınlaştırın:

Görünüm / destek tablolarının şeması, eğer yardımcı olursa: https://pastebin.com/wh1sRcbQ

Notlar:

• Endeksler birleştirildi, istatistikler güncel.
• Başlangıçta sorgu görünümü karşı satır içi, ama denemek ve stabilize yardımcı olmak için SPROC taşındı. Yardım etmedi.
• WITH OPTION (RECOMPILE);İpucu ekleme (işe yaramadı, bu yüzden parametre kokusu olamaz mı?)
• Sistemdeki diğer sorgular da bazen yavaş çalışır ve planlarında belirgin bir sorun yoktur.
• Kilitlenebilir mi? Nasıl onaylayacağınızdan emin değilim.

Sonra ne deneyebilirim hakkında herhangi bir fikir?

Teşekkürler

Ben gerçekten kullanarak OPTION (RECOMPILE)parametre koklama olasılığını ortadan kaldırmak için etkili bir yol olduğunu sanmıyorum .

Parametre koklaması, SQL belirli bir sorgu hakkında karıştığında ve yeni parametreleri gördüğünden yeni olduğunu düşündüğünde gerçekleşir. Yavaş çünkü yeni bir yürütme planı oluşturmak için fazladan zaman gerekiyor.

Tüm bu seçenek, SQL'i hemen hemen aynı şey olan yeni bir plan üretmeye zorlamaktır. Bunun yerine, bu ipucunu kullanarak varsayılan parametreler eklemeyi düşünebilirsiniz:

OPTION(OPTIMIZE FOR(@LocationIds='xx',@StatusType='xx'))

Varsayılan için parametre seçerken, istatistiksel olarak temsili bir küme kullandığınızdan emin olun.
Bu, her seferinde aynı planı kullanmaya zorlayacak ve parametre koklama olasılığını ortadan kaldıracaktır. Bunu yaptıktan ve yardımcı olmadığını belirledikten sonra, parametre koklamasını bir olasılık olarak reddetmek muhtemelen güvenlidir.

Belki de düzeni zorlamaya çalışın, bu yüzden muhtemelen her zaman daha küçük tabloyla (değişken) başlıyorsunuz. Bu görünümler ile zor olsa olsun ...

    SELECT  -- lots of fields
    FROM    @LocationIds [b] WITH (NOEXPAND)
            INNER JOIN  [dbo].[ListingSearchView][a] WITH (NOEXPAND) 
                ON [a].[LocationId] = [b].[Id]
    WHERE   [a].[StatusType] = @statusType
    OPTION (FORCE ORDER);

veya genellikle tablo değişkenini görünüme birleştirmek istediğiniz bir döngü birleştirmeyi zorlayabilirsiniz, bu da düzeni zorlar ...

    SELECT  -- lots of fields
    FROM    @LocationIds [b] WITH (NOEXPAND)
            INNER LOOP JOIN  [dbo].[ListingSearchView][a] WITH (NOEXPAND) 
                ON [a].[LocationId] = [b].[Id]
    WHERE   [a].[StatusType] = @statusType
    --leaving this here so you don't get an annoying warning 
    OPTION (FORCE ORDER);

Mağaza yordamının adını Sorgu Düzenleyicisi'ne yazın, ardından Mağaza işlemini seçin. adını seçin ve ardından Tahmini Yürütme Planını seçin veya (Ctrl + L) simgesini tıklayın. bunun görüntüsünün altında.

ardından Yürütme planları Sorgu Düzenleyicisi'nin altındaki Mesajlar Sekmesinin hemen yanında gösterilir. yeşil renkli çizgilerde eksik Dizin ayrıntılarını gösterir ve buna sağ tıklayın. Sonra yeni sorgu yeni sekmede açın ve sonra INDEX oluşturun. sonra Sorgunuz hızlı çalışır.

Bu yüzden yavaş çalışan Sorgu Teşhis için bu yöntemi kullandım. ve ayrıca kullanabileceğiniz çok fazla sorgu veya yöntem var.

Sorunun engellenmekte olduğunu düşünüyorsanız, iyimser işlem yalıtım düzeyini kullanmanızı öneririm Taahhüt Edilen Anlık Görüntüyü Oku (bunun tempDB'nize ek yük getireceğini unutmayın).

REFERANS: https://docs.microsoft.com/tr-tr/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server

Sorun okuma / yazma engellemesinde değil, görünümünüze dizin eklemeyi deneyebilirsiniz (dizinlerin en iyi seçimi verilerinizin seçiciliğine bağlıdır)

CREATE NONCLUSTERED INDEX IX_ListingSearchView (LocationID, StatusType) INCLUDE (other columns...)