На първо място, това са два различни модела на данни, подходящи за различни цели.
Като се има предвид това, очаквам вторият модел да бъде по-бърз за агрегиране, просто защото данните са опаковани по-компактно, следователно се нуждаят от по-малко I/O:
- ГРУПАТА BY в първия модел може да бъде задоволена от пълен сканирайте в индекса
{size, price}. Алтернативата на индекса е твърде бавна, когато данните са твърде големи, за да се поберат в RAM. - Заявката във втория модел може да бъде удовлетворена чрез пълно сканиране на таблицата. Не е необходим индекс.
Тъй като първият подход изисква таблица + индекс, а вторият само таблицата, използването на кеша е по-добро във втория случай. Дори ако пренебрегнем кеширането и сравним индекса (без таблица) в първия модел с таблицата във втория модел, подозирам, че индексът ще бъде по-голям от таблицата, просто защото физически записва size и има неизползвани "дупки", типични за B-Trees (въпреки че същото важи и за таблицата, ако е клъстериран
).
И накрая, вторият модел няма допълнителни разходи за поддръжка на индекса, което може да повлияе на производителността INSERT/UPDATE/DELETE.
Освен това, можете да помислите за кеширане на SUM и COUNT в отделна таблица, съдържаща само един ред. Актуализирайте както SUM, така и COUNT чрез тригери всеки път, когато се вмъкне, актуализира или изтрие ред в основната таблица. След това можете лесно да получите текущата средна стойност, просто като разделите SUM и COUNT.
Но наистина трябва да мерите за представителни количества данни, за да сме сигурни.
Тъй като във вашата заявка няма клауза WHERE, всички редове ще бъдат сканирани. Индексите са полезни само за получаване на сравнително малко подмножество от редове на таблицата (а понякога и за сканиране само за индекс ). Като грубо правило, ако са необходими повече от 10% от редовете в таблицата, индексите няма да помогнат и СУБД често избира пълно сканиране на таблицата, дори когато има налични индекси.
