Především se jedná o dva různé datové modely vhodné pro různé účely.
Jak již bylo řečeno, očekával bych, že druhý model bude rychlejší pro agregaci, jednoduše proto, že data jsou zabalena kompaktněji, a proto potřebují méně I/O:
- Skupina GROUP BY v prvním modelu může být uspokojena plným naskenujte index
{size, price}. Alternativa k indexování je příliš pomalá, když jsou data příliš velká a nevejdou se do paměti RAM. - Dotaz ve druhém modelu lze uspokojit úplným prohledáním tabulky. Není potřeba žádný index.
Vzhledem k tomu, že první přístup vyžaduje tabulku + index a druhý pouze tabulku, je využití cache lepší ve druhém případě. I když budeme ignorovat ukládání do mezipaměti a porovnáme index (bez tabulky) v prvním modelu s tabulkou ve druhém modelu, mám podezření, že index bude větší než tabulka, jednoduše proto, že fyzicky zaznamenává size a má nevyužité "díry" typické pro B-Stromy (i když totéž platí pro tabulku, pokud je clustered
).
A konečně, druhý model nemá režii na údržbu indexu, což by mohlo ovlivnit výkon INSERT/UPDATE/DELETE.
Kromě toho můžete zvážit uložení SUM a COUNT do mezipaměti v samostatné tabulce obsahující pouze jeden řádek. Aktualizujte pomocí spouštěčů SUM i COUNT při každém vložení, aktualizaci nebo odstranění řádku v hlavní tabulce. Pak můžete snadno získat aktuální AVG, jednoduše vydělením SUM a COUNT.
Ale měli byste opravdu měřit na reprezentativním množství dat.
Protože váš dotaz neobsahuje klauzuli WHERE, budou prohledány všechny řádky. Indexy jsou užitečné pouze pro získání relativně malé podmnožiny řádků tabulky (a někdy pro prohledávání pouze indexu ). Hrubým pravidlem je, že pokud je potřeba více než 10 % řádků v tabulce, indexy nepomohou a DBMS se často rozhodne pro úplné prohledání tabulky, i když jsou indexy k dispozici.