Allereerst zijn dit twee verschillende datamodellen die geschikt zijn voor verschillende doeleinden.
Dat gezegd hebbende, zou ik verwachten dat het tweede model sneller zal zijn voor aggregatie, simpelweg omdat de gegevens compacter zijn verpakt en daarom minder I/O nodig hebben:
- Aan de GROUP BY in het eerste model kan worden voldaan door een volledige scan op de index
{size, price}. Het alternatief voor index is te traag wanneer de gegevens te groot zijn om in het RAM-geheugen te passen. - Aan de vraag in het tweede model kan worden voldaan door een volledige tabelscan. Geen index nodig.
Aangezien de eerste benadering tabel + index vereist en de tweede alleen de tabel, is het cachegebruik in het tweede geval beter. Zelfs als we caching buiten beschouwing laten en de index (zonder tabel) in het eerste model vergelijken met de tabel in het tweede model, vermoed ik dat de index groter zal zijn dan de tabel, simpelweg omdat het fysiek de size registreert en heeft ongebruikte "gaten" die typisch zijn voor B-Trees (hoewel hetzelfde geldt voor de tabel als deze geclusterd
).
En tot slot heeft het tweede model geen overhead voor indexonderhoud, wat van invloed zou kunnen zijn op de INSERT/UPDATE/DELETE-prestaties.
Anders dan dat, kunt u overwegen de SUM en COUNT in een aparte tabel met slechts één rij te cachen. Werk zowel de SUM als COUNT bij via triggers wanneer een rij wordt ingevoegd, bijgewerkt of verwijderd in de hoofdtabel. U kunt dan eenvoudig de huidige AVG krijgen door SUM en COUNT te delen.
Maar je moet echt meten op representatieve hoeveelheden gegevens om zeker te zijn.
Aangezien er geen WHERE-clausule in uw zoekopdracht is, worden alle rijen gescand. Indexen zijn alleen nuttig voor het verkrijgen van een relatief kleine subset van tabelrijen (en soms voor alleen-index scans ). Als vuistregel geldt dat als meer dan 10% van de rijen in de tabel nodig is, indexen niet helpen en het DBMS vaak kiest voor een volledige tabelscan, zelfs als indexen beschikbaar zijn.