Pertama-tama, ini adalah dua model data berbeda yang cocok untuk tujuan berbeda.
Meskipun demikian, saya berharap model kedua akan lebih cepat untuk agregasi, hanya karena data dikemas lebih kompak, sehingga membutuhkan lebih sedikit I/O:
- GROUP BY pada model pertama dapat dipenuhi dengan penuh pindai pada indeks
{size, price}. Alternatif untuk mengindeks terlalu lambat ketika data terlalu besar untuk muat di RAM. - Kueri dalam model kedua dapat dipenuhi dengan pemindaian tabel lengkap. Tidak perlu indeks.
Karena pendekatan pertama membutuhkan tabel + indeks dan yang kedua hanya tabel, penggunaan cache lebih baik dalam kasus kedua. Bahkan jika kita mengabaikan caching dan membandingkan indeks (tanpa tabel) pada model pertama dengan tabel pada model kedua, saya menduga indeks akan lebih besar dari tabel, hanya karena secara fisik mencatat size dan memiliki "lubang" yang tidak digunakan yang khas untuk B-Trees (meskipun hal yang sama berlaku untuk tabel jika berkelompok
).
Dan terakhir, model kedua tidak memiliki overhead pemeliharaan indeks, yang dapat memengaruhi kinerja INSERT/UPDATE/DELETE.
Selain itu, Anda dapat mempertimbangkan untuk menyimpan SUM dan COUNT dalam tabel terpisah yang hanya berisi satu baris. Perbarui SUM dan COUNT melalui pemicu setiap kali baris dimasukkan, diperbarui, atau dihapus di tabel utama. Anda kemudian dapat dengan mudah mendapatkan AVG saat ini, cukup dengan membagi SUM dan COUNT.
Tapi Anda harus benar-benar mengukur pada jumlah data yang representatif untuk memastikannya.
Karena tidak ada klausa WHERE dalam kueri Anda, semua baris akan dipindai. Indeks hanya berguna untuk mendapatkan subset baris tabel yang relatif kecil (dan terkadang untuk scan hanya indeks ). Sebagai aturan umum, jika lebih dari 10% baris dalam tabel diperlukan, indeks tidak akan membantu dan DBMS akan sering memilih pemindaian tabel penuh bahkan ketika indeks tersedia.
