Лоши оценки за кардиналност, идващи от планове за изпълнение на SSMS

Трябва да благодаря на няколко души за скорошна актуализация на SQL Sentry Plan Explorer. Брук Филпот (@Macromullet) и Грег Гонзалес (блог | @SQLsensei), разбира се, за R &D и за ровене в кода и сортирането му. Но също и на Пол Уайт (блог | @SQL_kiwi) за това, че беше упорит да ни помага да валидираме поправките.

Проблемът, който Пол открива, е, че SQL Server 2008+ обърква оценките за кардиналност при определени заявки, когато се включват търсения на ключ или RID. Ще оставя по-дълбокото обяснение на публикацията в блога на Пол и грешката, която той подаде в Connect, но накратко, ние вземахме тези погрешно представени оценки, вярвахме им и ги екстраполирахме, за да ви покажем „по-добра“ информация. За съжаление, както обяснява Пол, бяхме измамени.

Пол показва следната заявка спрямо копие на AdventureWorks 2005.

SELECT
    th.ProductID,
    th.TransactionID,
    th.TransactionDate
FROM Production.TransactionHistory AS th 
WHERE 
    th.ProductID = 1 
    AND th.TransactionDate BETWEEN '20030901' AND '20031231';

Management Studio дава следния план, точно както го описа Пол:

В Plan Explorer се опитахме да бъдем полезни, като умножихме приблизителния брой редове (закръглено до 17) по броя на изпълненията (45) и излязохме с 765:

За повечето оператори този подход дава правилните данни, но поради тази грешка в SQL Server, той не е правилен за търсене на ключ/RID. Коригирахме се за това и пуснахме съответната корекция в 7.2.42.0 (изтеглете я сега!). Графичният план вече правилно показва правилния брой редове и за двете изчислени:

И действително:

Ще повторя предупреждението на Пол:Внимавайте за лоши оценки на кардиналността, когато предикат се прилага като част от търсене.

Имаше някои по-сложни проблеми, причинени от тези подвеждащи оценки, които също разгледахме. Ще блога за някои от тях в последваща публикация – за тази публикация просто исках да демонстрирам, че бързо разрешихме конкретния проблем, който Пол подчерта в публикацията си.