Bất lợi về hiệu suất sử dụng slug làm khóa chính / _id trong mongo?

Theo tôi, không. Sự khác biệt về hiệu suất sẽ không đáng kể đối với hầu hết các trường hợp ( ngoại trừ phân trang ), nhưng

• Cuộc thảo luận cũ về khóa chính thay thế xuất hiện. Một "slug" không phải là một chìa khóa tự nhiên. Đúng, nó phải là duy nhất, nhưng như bạn đã chỉ ra, việc thay đổi slug không phải là không thể. Chỉ điều này thôi cũng khiến tôi không phải bận tâm ...
• Có _id đơn điệu key có thể giúp bạn tránh khỏi một số vấn đề đau đầu, quan trọng nhất là tránh phân trang đắt tiền qua skip và take (sử dụng $lt / $gt trên _id thay vào đó).
• Có giới hạn về độ dài chỉ mục tối đa trong mongodb ít hơn hơn 1024 byte. Mặc dù không đẹp nhưng URL được phép là lâu hơn nữa . Nếu ai đó đã nhập một slug dài hơn, nó sẽ không được tìm thấy vì nó đã âm thầm bị loại khỏi chỉ mục.
• Bạn nên có một giao diện nhất quán, tức là sử dụng cùng một loại _id trên tất cả, hoặc ít nhất, hầu hết các đối tượng của bạn. Trong mã của mình, tôi có một ngoại lệ duy nhất là tôi đang sử dụng một mã băm đặc biệt làm id vì giá trị không thể thay đổi, bộ sưu tập có tốc độ ghi cực cao và dung lượng lớn.
• Giả sử bạn muốn liên kết đến bài viết trong giao diện quản lý của mình (không phải trang web công khai), bạn sẽ sử dụng liên kết nào? Bình thường là id, nhưng bây giờ id và slug tương đương nhau. Giờ đây, một lỗi đơn giản (chẳng hạn như cho phép một slug trống) sẽ khó có thể khắc phục được vì người dùng thậm chí không thể truy cập vào giao diện quản lý nữa.
• Bạn sẽ giải quyết các vấn đề về bộ ký tự. Tôi khuyên bạn thậm chí không nên sử dụng slug để tra cứu bài viết, nhưng hash của slug .

Về cơ bản, bạn sẽ kết thúc với một lược đồ như

{ "_id" : ObjectId("a237b45..."), // PK
  "slug" : "mongodb-is-fun", // not indexed
  "hash" : "5af87c62da34" } // indexed, unique