Ik moet een paar mensen bedanken voor een recente update van SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) en Greg Gonzalez (blog | @SQLsensei), natuurlijk voor R&D en voor het graven in de code en het uitzoeken ervan. Maar ook aan Paul White (blog | @SQL_kiwi) voor zijn volharding in het helpen valideren van de oplossingen.
Het probleem dat Paul ontdekte, is dat SQL Server 2008+ kardinaliteitsschattingen op bepaalde query's verknoeit als er sleutel- of RID-zoekopdrachten bij betrokken zijn. Ik laat de diepere uitleg over aan de blogpost van Paul en de bug die hij op Connect heeft ingediend, maar om een lang verhaal kort te maken, we namen deze verkeerd weergegeven schattingen, geloofden ze en extrapoleerden ze om je "betere" informatie te tonen. Helaas, zoals Paul uitlegt, werden we gedupeerd.
Paul toont de volgende query tegen een kopie van 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 levert het volgende plan op, precies zoals Paul het beschreef:
In Plan Explorer probeerden we behulpzaam te zijn door het geschatte aantal rijen (afgerond op 17) te vermenigvuldigen met het aantal uitvoeringen (45), en kwamen uit op 765:
Voor de meeste operators levert deze aanpak de juiste gegevens op, maar door deze bug in SQL Server is het niet correct voor key/RID-lookups. We hebben dat aangepast en de juiste oplossing uitgebracht in 7.2.42.0 (download het nu!). Het grafische plan toont nu correct de juiste rijtellingen voor beide geschatte:
En actueel:
Ik herhaal de waarschuwing van Paul:Pas op voor slechte kardinaliteitsschattingen wanneer een predikaat wordt toegepast als onderdeel van een zoekopdracht.
Er waren enkele meer complexe problemen veroorzaakt door deze misleidende schattingen, die we ook hebben aangepakt. Over een paar daarvan zal ik in een vervolgbericht bloggen - voor dit bericht wilde ik alleen maar laten zien dat we het specifieke probleem dat Paul in zijn bericht benadrukte snel hebben opgelost.