Theo tài liệu MongoDB, nói chung không cần phải xây dựng lại các chỉ mục thường xuyên.
LƯU Ý :Mọi lời khuyên về bộ nhớ trở nên thú vị hơn với MongoDB 3.0+, đã giới thiệu API công cụ lưu trữ có thể cắm được . Nhận xét của tôi bên dưới đặc biệt liên quan đến công cụ lưu trữ MMAP mặc định trong MongoDB 3.0 trở về trước. WiredTiger và các công cụ lưu trữ khác có các cách triển khai lưu trữ khác nhau cho dữ liệu và chỉ mục.
Có thể có một số lợi ích trong việc xây dựng lại chỉ mục bằng công cụ lưu trữ MMAP nếu:
-
Một chỉ mục đang sử dụng một lượng không gian lớn hơn dự kiến so với dữ liệu. Lưu ý:bạn cần theo dõi dữ liệu lịch sử và kích thước chỉ mục để có đường cơ sở so sánh.
-
Bạn muốn chuyển từ định dạng chỉ mục cũ hơn sang định dạng mới hơn. Nếu lập chỉ mục là cố vấn, điều này sẽ được đề cập trong ghi chú nâng cấp. Ví dụ:MongoDB 2.0 đã giới thiệu đáng kể cải tiến hiệu suất chỉ mục vì vậy ghi chú phát hành bao gồm một chỉ mục được đề xuất sang định dạng v2.0 sau khi nâng cấp. Tương tự, MongoDB 2.6 đã giới thiệu
2dsphere(v2.0) chỉ mục có một hành vi mặc định khác (thưa thớt theo mặc định). Các chỉ mục hiện có không được xây dựng lại sau khi nâng cấp phiên bản chỉ mục; việc lựa chọn nếu / khi nào để nâng cấp được để cho người quản trị cơ sở dữ liệu. -
Bạn đã thay đổi
_idđịnh dạng cho một tập hợp đến hoặc từ một khóa tăng đơn điệu (ví dụ:ObjectID) thành một giá trị ngẫu nhiên. Điều này hơi bí truyền một chút, nhưng có một tính năng tối ưu hóa chỉ mục chia các nhóm b-tree 90/10 (thay vì 50/50) nếu bạn đang chèn_ids luôn tăng (ref: SERVER-983 ). Nếu bản chất của_idcủa bạn s thay đổi đáng kể, có thể xây dựng b-tree hiệu quả hơn với chỉ mục lại.
Để biết thêm thông tin về hành vi chung của cây B, hãy xem: Wikipedia:B-tree
Trực quan hóa việc sử dụng chỉ mục
Nếu bạn thực sự tò mò muốn tìm hiểu sâu hơn về phần bên trong chỉ mục, có một số lệnh / công cụ thử nghiệm bạn có thể thử. Tôi hy vọng chúng chỉ giới hạn trong MongoDB 2.4 &2.6:
