sql >> Databáze >  >> Database Tools >> SSMS

Špatné odhady mohutnosti z plánů SSMS – redux

Před více než třemi lety jsem zveřejnil opravu pro Plan Explorer týkající se špatných odhadů mohutnosti, které SQL Server Showplan XML produkoval, v případě vyhledávání klíčů/RID s predikátem filtru v SQL Server 2008 a vyšší. Myslel jsem, že by bylo zajímavé podívat se zpět a jít trochu podrobněji o jednom z těchto plánů a iteracích, kterými jsme prošli, abychom se ujistili, že zobrazujeme správné metriky bez ohledu na to, co zobrazuje Management Studio. Tuto práci opět z velké části odvedli Brooke Philpott (@MacroMullet) a Greg Gonzalez (@SQLsensei) a s velkým přínosem od Paula Whitea (@SQL_Kiwi).

To je docela podobné dotazu, který jsem uvedl ve svém dřívějším příspěvku, který přišel od Paula (a jehož přesnou reprodukci v moderních verzích AdventureWorks, kde se změnila přinejmenším data transakcí, by dalo práci):

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';

Plán z Management Studio vypadal dostatečně správně:

Když se však podíváte blíže, zdá se, že ShowPlan posunul odhadovaný počet poprav z vyhledávání klíčů přímo na odhadovaný počet řádků pro konečnou výměnu:

Na první pohled vypadá grafický diagram plánu v Průzkumníku plánů docela podobně jako plán, který vytváří SSMS:

Nyní, v procesu vývoje Plan Explorer, jsme objevili několik případů, kdy ShowPlan nevychází úplně správně. Nejviditelnějším příkladem jsou procenta sčítající až přes 100 %; máme to správně v případech, kdy jsou SSMS směšně vypnuté (dnes to vidím méně často než dříve, ale stále se to stává).

Dalším případem je situace, kdy počínaje SQL Serverem 2008 začal SSMS vkládat celkový odhadovaný počet řádků místo řádků na každé spuštění spolu s vyhledáváními, ale pouze v případech, kdy je do vyhledávání vložen predikát (jako je případ v této chybě hlášené Paulem, a toto novější pozorování Joeyho D'Antoniho). V dřívějších verzích SQL Serveru (a s funkcemi a spooly) bychom obvykle zobrazovali odhadovaný počet řádků pocházejících z vyhledávání vynásobením odhadovaných řádků na spuštění (obvykle 1) odhadovaným počtem řádků podle SSMS. Ale s touto změnou bychom to přepočítali, protože operátor už to počítá. Takže v dřívějších verzích Plan Explorer, oproti 2008+, byste viděli tyto podrobnosti v popiscích, spojnicích nebo v různých mřížkách:

(Odkud pochází 1 721? 67,5 odhadovaných spuštění x 25,4927 odhadovaných řádků.)

V roce 2012 jsme část tohoto problému vyřešili tím, že jsme již tuto matematickou operaci neprováděli a spoléhali jsme pouze na odhadovaný počet řádků vycházející z vyhledávání klíčů. To bylo téměř správné, ale stále jsme spoléhali na odhadovaný počet řádků, který nám ShowPlan poskytl pro konečnou výměnu:

I tento problém jsme rychle vyřešili, ve verzi 7.2.42.0 (vydaná na Hallowe'en 2012), a nyní máme pocit, že poskytujeme informace, které jsou mnohem přesnější než Management Studio (ačkoli budeme tuto chybu od Paula sledovat) :

To se zjevně stalo již dávno, ale stále jsem si myslel, že by bylo zajímavé se o to podělit. Pokračujeme ve vylepšování Plan Exploreru, abychom vám poskytovali co nejpřesnější informace, a o několik dalších těchto pecek se podělím v nadcházejících příspěvcích.


  1. Řetězec SQL Select nefunguje

  2. Chyba MySQL - #1932 - Tabulka 'phpmyadmin.pma user config' v enginu neexistuje

  3. Chyba #1046 – Není vybrán žádný import databáze SQL na XAMPP

  4. Při připojování k MySQL v aplikaci ve službě Azure App Service došlo k chybě přístupu odepřen