Hãy đi đến câu hỏi của bạn lần lượt:
Việc xem xét các chỉ số hiệu suất chỉ từ một lần thực thi thực sự không phải là cách nó hoạt động. Bạn nên lấy mức trung bình của một số lần thực thi trước khi kết luận vì có một số yếu tố xảy ra. Vì vậy, nếu một truy vấn truy cập tài liệu đã được lưu trong bộ nhớ cache từ một truy vấn trước đó, nó sẽ nhanh hơn.
Ngoài ra trong tập hợp MongoDB chỉ sử dụng các chỉ mục ở phần đầu nếu có. Ví dụ:$match và $sort các pha có thể sử dụng các chỉ mục. Trong trường hợp của bạn $match là giai đoạn đầu tiên, vì vậy đó là một chiến thắng.
Trong MongoDB, dữ liệu được lưu trữ trong BSON , vì vậy ngày về cơ bản là số khi chúng được so sánh. Vì vậy, không có sự khác biệt.
Mặc dù tôi chưa thử nghiệm nó, tôi thực sự nghi ngờ rằng phương pháp time_bucket sẽ cho phản hồi nhanh hơn. Kể từ khi created_at sẽ luôn tăng, chỉ số, trong trường hợp này, cũng sẽ được thêm vào cuối mà không có time_bucket. Hơn nữa, kích thước chỉ mục sẽ tương đối lớn khi được tạo trên một mảng hơn là trên một trường ngày tháng đơn giản. Điều đó sẽ không gây ra vấn đề khớp chỉ mục trong RAM.
Sử dụng time_bucket có ý nghĩa khi bạn đang sử dụng một số hàm trên trường ngày trước khi khớp. Nếu bạn chỉ trích xuất năm từ trường ngày trước khi khớp, nó sẽ làm cho chỉ mục hiện có vào ngày đó trở nên vô dụng.
Tốt hơn hết là truyền các tham số của bạn để khớp với kiểu dữ liệu trong cơ sở dữ liệu thay vì ngược lại.
Vâng nó có thể. Nếu đó là $and , bạn chỉ cần chỉ định tất cả các bộ lọc của mình được phân tách bằng dấu phẩy trong $match giai đoạn. Nếu đó là $or sử dụng $or
nhà điều hành.
Nếu bạn có hai $macth từng giai đoạn MongoDB kết hợp nó thành một giai đoạn
. Vì vậy, bạn không cần phải lo lắng về việc thêm kết quả của nhiều giai đoạn trận đấu.
Bây giờ là Tối ưu hóa của bạn Điểm
Có, truy vấn được đề cập nhanh hơn nhiều.
Nếu kích thước của tài liệu bị giảm trong nhóm $group giai đoạn bằng cách sử dụng $project , thì đúng là như vậy.
Nó không nhất thiết đúng nhưng nó thường là như vậy. Bạn có thể kiểm tra câu trả lời này .
