Først og fremmest er der tale om to forskellige datamodeller, der egner sig til forskellige formål.
Når det er sagt, ville jeg forvente, at den anden model vil være hurtigere til aggregering, simpelthen fordi dataene er pakket mere kompakt og derfor har brug for mindre I/O:
- GROUP BY i den første model kan opfyldes med en fuld scan på indekset
{size, price}. Alternativet til indeks er for langsomt, når dataene er for store til at passe i RAM. - Forespørgslen i den anden model kan opfyldes ved en fuld tabelscanning. Intet indeks er nødvendigt.
Da den første tilgang kræver tabel + indeks og den anden kun tabellen, er cache-udnyttelsen bedre i det andet tilfælde. Selvom vi ser bort fra caching og sammenligner indekset (uden tabel) i den første model med tabellen i den anden model, formoder jeg, at indekset vil være større end tabellen, simpelthen fordi det fysisk registrerer size og har ubrugte "huller" typisk for B-Trees (selvom det samme gælder for bordet, hvis det er klyngede
).
Og endelig har den anden model ikke indeksvedligeholdelsesomkostningerne, hvilket kan påvirke INSERT/UPDATE/DELETE ydeevnen.
Bortset fra det, kan du overveje at cache SUM og COUNT i en separat tabel, der kun indeholder en række. Opdater både SUM og COUNT via triggere, hver gang en række indsættes, opdateres eller slettes i hovedtabellen. Du kan derefter nemt få det aktuelle AVG, blot ved at dividere SUM og COUNT.
Men du bør virkelig måle på repræsentative mængder af data for at være sikker.
Da der ikke er nogen WHERE-klausul i din forespørgsel, vil alle rækker blive scannet. Indekser er kun nyttige til at få et relativt lille undersæt af tabellens rækker (og nogle gange for scanninger kun for indeks ). Som en grov tommelfingerregel, hvis mere end 10 % af rækkerne i tabellen er nødvendige, hjælper indekser ikke, og DBMS vil ofte vælge en fuld tabelscanning, selv når indekser er tilgængelige.