Trước hết, đây là hai mô hình dữ liệu khác nhau phù hợp với các mục đích khác nhau.
Điều đó đang được nói, tôi hy vọng mô hình thứ hai sẽ nhanh hơn để tổng hợp, đơn giản vì dữ liệu được đóng gói nhỏ gọn hơn, do đó cần ít I / O hơn:
- GROUP BY trong mô hình đầu tiên có thể được đáp ứng bởi đầy đủ quét trên chỉ mục
{size, price}. Lựa chọn thay thế cho chỉ mục quá chậm khi dữ liệu quá lớn không thể vừa với RAM. - Có thể đáp ứng truy vấn trong mô hình thứ hai bằng cách quét toàn bộ bảng. Không cần chỉ mục.
Vì cách tiếp cận đầu tiên yêu cầu bảng + chỉ mục và cách tiếp cận thứ hai chỉ là bảng, nên việc sử dụng bộ nhớ cache tốt hơn trong trường hợp thứ hai. Ngay cả khi chúng tôi bỏ qua bộ nhớ đệm và so sánh chỉ mục (không có bảng) trong mô hình đầu tiên với bảng trong mô hình thứ hai, tôi nghi ngờ chỉ mục sẽ lớn hơn bảng, đơn giản vì nó ghi lại size về mặt vật lý và có các "lỗ" không được sử dụng điển hình cho B-Trees (mặc dù điều này cũng đúng với bảng nếu nó là clustered
).
Và cuối cùng, mô hình thứ hai không có chi phí duy trì chỉ mục, điều này có thể ảnh hưởng đến hiệu suất INSERT / UPDATE / DELETE.
Ngoài ra, bạn có thể xem xét lưu vào bộ nhớ đệm SUM và COUNT trong một bảng riêng biệt chỉ chứa một hàng. Cập nhật cả SUM và COUNT thông qua trình kích hoạt bất cứ khi nào một hàng được chèn, cập nhật hoặc xóa trong bảng chính. Sau đó, bạn có thể dễ dàng lấy AVG hiện tại, đơn giản bằng cách chia SUM và COUNT.
Nhưng bạn thực sự nên đo lường về lượng dữ liệu đại diện để chắc chắn.
Vì không có mệnh đề WHERE trong truy vấn của bạn, tất cả các hàng sẽ được quét. Chỉ mục chỉ hữu ích để lấy một tập hợp con tương đối nhỏ các hàng của bảng (và đôi khi đối với chỉ quét chỉ mục ). Theo nguyên tắc chung, nếu cần hơn 10% số hàng trong bảng, các chỉ mục sẽ không hữu ích và DBMS thường sẽ chọn quét toàn bộ bảng ngay cả khi có chỉ mục.
