För det första är det här två olika datamodeller som är lämpliga för olika ändamål.
Som sagt, jag förväntar mig att den andra modellen kommer att vara snabbare för aggregering, helt enkelt för att data packas mer kompakt och därför behöver mindre I/O:
- GROUP BY i den första modellen kan uppfyllas med en full skanna på indexet
{size, price}. Alternativet till index är för långsamt när data är för stor för att få plats i RAM. - Frågan i den andra modellen kan tillfredsställas med en fullständig tabellskanning. Inget index behövs.
Eftersom det första tillvägagångssättet kräver tabell + index och det andra bara tabellen, är cacheutnyttjandet bättre i det andra fallet. Även om vi bortser från cachelagring och jämför indexet (utan tabell) i den första modellen med tabellen i den andra modellen, misstänker jag att indexet kommer att vara större än tabellen, helt enkelt för att det fysiskt registrerar size och har oanvända "hål" som är typiska för B-Trees (även om detsamma gäller för tabellen om det är klustrade
).
Och slutligen, den andra modellen har inte indexunderhållskostnader, vilket kan påverka INSERT/UPDATE/DELETE-prestandan.
Annat än det kan du överväga att cachelagra SUMMA och COUNT i en separat tabell som bara innehåller en rad. Uppdatera både SUMMA och COUNT via triggers när en rad infogas, uppdateras eller tas bort i huvudtabellen. Du kan sedan enkelt få aktuell AVG, helt enkelt genom att dividera SUM och COUNT.
Men du borde verkligen mäta på representativa mängder data för att vara säker.
Eftersom det inte finns någon WHERE-sats i din fråga, kommer alla rader att skannas. Index är bara användbara för att få en relativt liten delmängd av tabellens rader (och ibland för genomsökningar endast för index ). Som en grov tumregel, om mer än 10 % av raderna i tabellen behövs, hjälper inte index och DBMS kommer ofta att välja en fullständig tabellsökning även när index är tillgängliga.