Vždy jsem považoval vynikající tabulku logického zpracování SQL od Itzika Ben-Gana za nesmírně užitečnou při uvažování o výkonu dotazování. I když byl graf vytvořen pro SQL Server, stále je použitelný pro jakýkoli databázový stroj, který se řídí standardem SQL, který také zahrnuje databázový stroj Access. Přestože rádi používáme databáze SQL Server, máme příležitostné databáze Accessu nebo aplikace Accessu, které vyžadují použití dotazů Accessu (např. dočasné tabulky pro vytváření sestav). Access nepřichází s efektními nástroji pro profilování, takže co máme dělat?
Jerry-rigging náš vlastní nástroj pro sledování
To mě přimělo k tomu, abych se divil – dalo by se určit, kdy se klauzule dotazu SQL provede a jak často? Přístup má prostředek k zobrazení plánů provádění, ale nezabývá se podrobnostmi o tom, jak a kdy se údaje zpracovávají. Existuje kruhový objezd, jak odvodit fyzické pořadí zpracování používané databázovým strojem Access:vlastní funkce VBA!
Trace veřejné funkce (název události jako řetězec, volitelná hodnota jako varianta) jako logická hodnota If IsMissing(Value) Then Debug.Print Název události, "#No Value#" Else Debug.Print Název události, Konec hodnoty If Trace =Funkce TrueEndTo lze uložit do standardního modulu. Poté můžeme vytvořit jednoduchou tabulku:
Sledování klauzulí dotazu Access
S tímto nastavením můžeme vytvořit Access dotaz a posypat
Trace
v různých částech dotazu Access. Zde je jeden příklad:SELECT c1.ColorID, Trace("SELECT") AS Ignorováno1, Trace("SELECT",c1.Color) AS Ignorováno2FROM tblColor AS c1 WHERE Trace("WHERE") <> 0 AND Trace("WHERE", c1 .Color) <> 0ORDER BY Trace("ORDER BY"), Trace("ORDER BY", c1.Color);Pokud poté otevřete dotaz v zobrazení datového listu a poté přejdete do bezprostředního okna VBIDE, měli byste vidět výstup takto:
KDE #No Value#ORDER BY #No Value#SELECT #No Value#WHERE RedORDER BY RedWHERE GreenORDER BY GreenWHERE BlueORDER BY BlueSELECT BlueSELECT GreenSELECT RedTo nám poskytuje určité informace o tom, jak Access řeší dotaz, což může být užitečné, když potřebujete optimalizovat dotaz s nízkou výkonností. Podívejme se, co se můžeme naučit:
- Vidíme, že pokud neexistují žádné odkazy na sloupce, je funkce VBA volána co nejdříve, protože Access rozpozná, že mohou mít pouze jednu hodnotu pro celou sadu výsledků, takže nemá smysl volat funkci znovu a znovu. získat stejnou odpověď. Můžete vidět, že
Trace
vyvolání bez 2. volitelného argumentu byla vyhodnocena jako první před všemi ostatními voláními obsahujícími odkaz na sloupec ve 2. volitelném argumentu. - Jako důsledek předchozího bodu, pokud vyvolání obsahuje odkaz na sloupec, musí být vyhodnocen alespoň jednou pro každý řádek. Můžete vidět, že při hodnocení klauzule procházíme každou hodnotu barvy.
- Vidíme, že pořadí je obecně podobné tomu, co vidíme v grafu Itzika Ben-Gana;
WHERE
je vyhodnocena co nejdříve,ORDER BY
se vyhodnotí poté, co odstraníme všechny nesplňující řádky, poté co zbyde,SELECT
se poté vyhodnotí. - Přestože bychom očekávali, že třídění bude použito po odfiltrování nezpůsobilých řádků, zdá se, že Access dává přednost pokusu seřadit výstup co nejdříve, možná proto, že je levnější vložit nový řádek do seřazeného seznam přes řazení celé sady.
Další experimenty a závěry
Můžete trochu experimentovat s jiným dotazem. Můžete například získat přehled o tom, kdy/často Access zpracovává GROUP BY
pomocí dotazu podobného tomuto:
SELECT c1.ColorID, Trace("SELECT") AS Ignored1FROM tblColor AS c1 INNER JOIN tblColor AS c2 ON c1.ColorID =c2.ColorIDWHERE Trace("WHERE") <> 0 AND Trace("WHERE", [c1 ].[Color]) <> 0GROUP BY c1.ColorID, Trace("GROUP BY", c1.Color)ORDER BY c1.ColorID;
To pak můžete použít ve spojení s JetShowPlan, abyste se dozvěděli více o tom, co databázový stroj skutečně dělá. Doufejme, že vám to může pomoci při získávání přehledů o tom, jak můžete zlepšit výkon vašeho dotazu Access. Jako problém můžete zdůvodnit, proč Access spouští GROUP BY
jak to dělá. Také vám doporučuji vyzkoušet otevření datového listu a posouvání. Potom zjistíte, že SELECT
bude přehodnocena jako výsledek navigace.
Měl bych zdůraznit, že výše uvedená technika nám poskytuje vhled do fyzického plán zpracování, spíše než logické pořadí zpracování, jak je popsáno v tabulce. V souladu s tím bychom měli očekávat, že plán se bude lišit pro různé objemy dat nebo pro různé dotazy. Musíme také vzít v úvahu přidání Trace
funkce může plán ovlivnit. Řekl bych však, že pokud vás tyto úvahy tak znepokojují, je pravděpodobně lepší přesunout tento dotaz a jeho podkladová data do databáze SQL Server, kde máte mnohem více možností pro optimalizaci výkonu dotazu.
Bavte se!
Potřebujete pomoci s dotazy na Microsoft Access? Zavolejte odborníkům na přístup na číslo (773) 809 5456 nebo pošlete týmu e-mail ještě dnes.