Sayfalandırıldığında SQL Server sorgusu yavaş

15

SQL Server 2012'de aşağıdaki T-SQL sorgusu ile bazı garip davranışlar görüyorum:

SELECT Id 
FROM dbo.Person 
WHERE CONTAINS(Name, '"John" AND "Smith"')
ORDER BY Name

Bu sorguyu tek başına yürütmek bana iki saniyeden kısa sürede yaklaşık 1.300 sonuç veriyor (tam metin dizini var Name)

Ancak, ben bu sorguyu değiştirdiğinizde:

SELECT Id 
FROM dbo.Person 
WHERE CONTAINS(Name, '"John" AND "Smith"')
ORDER BY Name
OFFSET 0 rows
FETCH NEXT 10 ROWS ONLY

Bana 10 sonuç vermek 20 saniyeden fazla sürüyor.

Aşağıdaki sorgu daha da kötüdür:

SELECT Id 
FROM ( 
    SELECT ROW_NUMBER() OVER (ORDER BY Name) AS RowNum, Id 
    FROM dbo.Person
    WHERE CONTAINS(Name, '"John" AND "Smith"') ) AS RowConstrainedResult 
WHERE RowNum >= 0 AND RowNum < 11 
ORDER BY RowNum

Tamamlanması 1,5 dakikadan fazla sürüyor!

Herhangi bir fikir?

Yavaş plan

Yavaş

Hızlı plan

Hızlı

sql-server sql-server-2012

— vrs
kaynak

İkinci sorgunuzu olarak değiştirirseniz ne olur SELECT TOP 10 * .... ORDER BY Name?

— Lamak

IX_PersonSearch dizini hangi sütunlarda yapılır? Tablodan * seçtiğiniz için ve kullanılan dizin tüm çıkış sütunlarını içermediğinden, önemli bir arama alıyorsunuz. Sadece ihtiyacınız olan sütunları seçmeniz ve sonra bunları kümelenmemiş dizine dizin sütunları olarak değil, dahil edilen sütunlar olarak eklemeniz gerektiğini düşünüyorum.

— Marcel N.

Size indeksleri masaya koyabilir misiniz?

3

Kimlik, her kümelenmemiş dizine her zaman dahil edilir. Bu, SQL Server'ın aramaları (kimliğe göre) anahtarlayabilmesidir.

— usr

1

Ne bahsetmeyi unuttum: Ben aynı sorguyu CONTAINS yerine LIKE ile yaptığınızda, çok hızlı. (Sayfalandırılmış veya değil)

7

Sadece TOP 10isme göre sıralamak istediğiniz gibi name, sırayla dizini aşağı çalışmak ve her satır CONTAINS(Name, '"John" AND "Smith"') )yüklem ile eşleşip eşleşmediğini görmek için daha hızlı olacağını düşünüyor .

Muhtemelen gerekli olan 10 eşleşmeyi bulmak için daha fazla satır gerekiyor ve beklediği gibi, bu kardinalite sorunu anahtar aramaların sayısıyla daha da artıyor.

Hızlı bir hack değiştirmektir bu planı kullanarak durdurmak için ORDER BYiçin ORDER BY Name + ''kullanan rağmen CONTAINSTABLEbirlikte FORCE ORDERçalışma da bağlanmamalıdır.

— Martin Smith
kaynak

3

Bu klasik seçicilikle ilgili yanlış anlama gibi görünüyor. Sorgunun "sürücüsü", istatistiklerle zenginleştirilemeyen tam metin araması olduğundan, bu konuda neler yapılabileceğinden emin değilim.

Yüklemeyi where containsbir inner join containstable( CONTAINSTABLE ) öğesine yeniden yazmayı deneyin ve planın şeklini zorlamak için birleştirme sırası ipuçları uygulayın.

Bu mükemmel bir çözüm değil çünkü bakım sorunları var, ancak başka bir yol göremiyorum.

— usr
kaynak

Cevabınız için teşekkürler, denedim. Yine de aynı sonuç: Sayfalandırma kullanılmadığında sorgu gerçekten hızlıdır.

Tamam, planı bir resim ve sorgunuz olarak gönderebilir misiniz? Sanırım henüz istenen şekli oluşturmayı başaramadık.

— usr

3

Sorunu çözmeyi başardım:

Soruda söylediğim gibi, tüm sütunlarda indeksler vardı + her sütun için istatistikler. (Eski LIKE sorguları nedeniyle) Tüm dizinleri ve istatistikleri kaldırdım, tam metin aramasını ve voilà'yı ekledim, sorgu gerçekten hızlı oldu.

Görünüşe göre indeksler farklı bir Uygulama Planına yol açtı.

Yardımınız için hepinize çok teşekkür ederim!

— vrs
kaynak

1

Dizini tamamen silmek, kullanılmasını önlemenin bir yoludur sanırım!

— Martin Smith