Tout d'abord, il s'agit de deux modèles de données différents adaptés à des fins différentes.
Cela étant dit, je m'attends à ce que le deuxième modèle soit plus rapide pour l'agrégation, simplement parce que les données sont compressées de manière plus compacte, nécessitant donc moins d'E/S :
- Le GROUP BY dans le premier modèle peut être satisfait par un complet scanner sur l'index
{size, price}. L'alternative à l'indexation est trop lente lorsque les données sont trop volumineuses pour tenir dans la RAM. - La requête du deuxième modèle peut être satisfaite par une analyse complète de la table. Aucun index nécessaire.
Étant donné que la première approche nécessite table + index et la seconde uniquement la table, l'utilisation du cache est meilleure dans le second cas. Même si nous ne tenons pas compte de la mise en cache et comparons l'index (sans table) du premier modèle avec la table du second modèle, je soupçonne que l'index sera plus grand que la table, simplement parce qu'il enregistre physiquement la size et a des "trous" inutilisés typiques pour les arbres B (bien que la même chose soit vraie pour la table si elle est cluster
).
Et enfin, le deuxième modèle n'a pas de surcharge de maintenance d'index, ce qui pourrait avoir un impact sur les performances INSERT/UPDATE/DELETE.
En dehors de cela, vous pouvez envisager de mettre en cache SUM et COUNT dans une table séparée contenant une seule ligne. Mettez à jour SUM et COUNT via des déclencheurs chaque fois qu'une ligne est insérée, mise à jour ou supprimée dans la table principale. Vous pouvez alors facilement obtenir l'AVG actuelle, simplement en divisant SUM et COUNT.
Mais vous devriez vraiment mesurer sur des quantités représentatives de données pour être sûr.
Puisqu'il n'y a pas de clause WHERE dans votre requête, toutes les lignes seront analysées. Les index ne sont utiles que pour obtenir un sous-ensemble relativement petit de lignes de table (et parfois pour analyses d'index uniquement ). En règle générale, si plus de 10 % des lignes de la table sont nécessaires, les index n'aideront pas et le SGBD optera souvent pour une analyse complète de la table même lorsque les index sont disponibles.
