Преди повече от три години публикувах за корекция на Plan Explorer по отношение на лошите оценки за мощността, които показваше XML Showplan на SQL Server, в случай на търсене на ключ/RID с предикат на филтър в SQL Server 2008 и по-нова версия. Мислех, че би било интересно да погледнем назад и да навлезем малко по-подробно за един от тези планове и итерациите, през които преминахме, за да гарантираме, че показваме правилни показатели, независимо от това, което показва Management Studio. Отново тази работа беше извършена до голяма степен от Брук Филпот (@MacroMullet) и Грег Гонзалес (@SQLsensei) и с голям принос от Пол Уайт (@SQL_Kiwi).
Това е доста подобно на заявката, която представих в моята по-ранна публикация, която дойде от Пол (и която ще изисква известна работа, за да се възпроизвежда точно в съвременните версии на AdventureWorks, където най-малкото датите на транзакциите са се променили):
SELECT
th.ProductID,
p.Name,
th.TransactionID,
th.TransactionDate
FROM Production.Product AS p
JOIN Production.TransactionHistory AS th ON
th.ProductID = p.ProductID
WHERE
p.ProductID IN (1, 2)
AND th.TransactionDate BETWEEN '20070901' AND '20071231'; Планът от Management Studio изглеждаше достатъчно правилен:
Въпреки това, ако погледнете по-отблизо, изглежда, че ShowPlan е изместил приблизителния брой изпълнения от търсенето на ключ направо до прогнозния брой редове за крайния обмен:
На пръв поглед диаграмата на графичния план в Plan Explorer изглежда доста подобна на плана, който SSMS произвежда:
Сега, в процеса на разработване на Plan Explorer, открихме няколко случая, в които ShowPlan не разбира правилно математиката си. Най-очевидният пример е процентите, достигащи над 100%; получаваме това правилно в случаите, когато SSMS е абсурдно изключен (виждам това по-рядко днес, отколкото преди, но все още се случва).
Друг случай е, когато, като се започне от SQL Server 2008, SSMS започна да поставя общи приблизителни редове вместо редове на изпълнение заедно с търсения, но само в случаите, когато предикат е избутан към търсенето (като случая в тази грешка, докладвана от Пол, и това по-ново наблюдение на Джоуи Д'Антони). В по-ранни версии на SQL Server (и с функции и пулове) обикновено показваме прогнозен брой редове, идващи от търсене, като умножаваме прогнозираните редове на изпълнение (обикновено 1) по прогнозния брой редове според SSMS. Но с тази промяна ще преброим, тъй като операторът вече прави тази математика. Така че в по-ранни версии на Plan Explorer, срещу 2008+, ще видите тези подробности в подсказките, линиите на конектора или в различните мрежи:
(Откъде идват 1721? 67,5 прогнозни изпълнения x 25,4927 прогнозни реда.)
Още през 2012 г. поправихме част от този проблем, като не изпълнявахме повече тази математическа операция и разчитахме единствено на приблизителния брой редове, идващи от ключовото търсене. Това беше почти правилно, но ние все още разчитахме на прогнозния брой редове, който ShowPlan ни предостави за окончателния обмен:
Бързо разгледахме и този проблем във версия 7.2.42.0 (издадена на Хелоуин 2012 г.) и сега смятаме, че предоставяме информация, която е много по-точна от Management Studio (въпреки че ще следим този бъг от Пол) :
Това явно се е случило много отдавна, но все пак реших, че ще е интересно да споделя. Продължаваме да подобряваме Plan Explorer, за да ви предоставим възможно най-точната информация и ще споделя още няколко от тези самородни елементи в предстоящите публикации.
