MongoDB修改唯一键技术咨询：将用户邮箱设为数据库唯一键

Hey there! Let's walk through how to handle modifying unique keys in MongoDB, given your current schema where you're using the user's email as the _id field (which is inherently unique in MongoDB). I’ll cover the most common scenarios you might run into:

Scenario 1: Switching to a different unique key field (instead of using email as _id) #

Maybe you want to use MongoDB's default ObjectId for _id instead, and make a separate email field your unique key. Here's how to do that:

1. Backup your data first—this is non-negotiable to avoid losing anything.
2. Add a new email field to all existing documents, copying the value from _id:

   db.users.updateMany({}, [{$set: {email: "$_id"}}])
   

3. If you want to replace _id with an ObjectId, you’ll need to reinsert your documents (since _id can’t be modified directly):
   • Export your collection: mongodump --db your-db-name --collection users
   • Edit the exported JSON/BSON files to replace the _id values with new ObjectId() instances, keeping the email field intact.
   • Drop the original collection: db.users.drop()
   • Reimport the modified data: mongorestore --db your-db-name --collection users path-to-dump-files
4. Create a unique index on the new email field to enforce uniqueness:

   db.users.createIndex({email: 1}, {unique: true})
   

   Pro tip: If some users might not have an email (unlikely in your case), add sparse: true to allow null values without violating uniqueness.

Scenario 2: Updating the value of an existing unique key (e.g., a user changes their email) #

Since _id is immutable in MongoDB, you can’t just edit it directly. Instead, you’ll need to copy the document, update the key, and delete the old one:

// 1. Fetch the user with the old email
const oldUser = db.users.findOne({_id: "old-email@example.com"});

// 2. Create a new document with the updated email as _id
const newUser = {...oldUser, _id: "new-email@example.com"};

// 3. Insert the new document and delete the old one
db.users.insertOne(newUser);
db.users.deleteOne({_id: "old-email@example.com"});

For atomicity (so you don’t end up with duplicate or missing data), use a transaction if you’re on MongoDB 4.0+:

const session = db.getMongo().startSession();
session.startTransaction();
try {
  const oldUser = db.users.findOne({_id: "old-email@example.com"}, {session});
  const newUser = {...oldUser, _id: "new-email@example.com"};
  db.users.insertOne(newUser, {session});
  db.users.deleteOne({_id: "old-email@example.com"}, {session});
  session.commitTransaction();
} catch (err) {
  session.abortTransaction();
  throw err;
} finally {
  session.endSession();
}

Scenario 3: Adjusting the rules for your unique index #

If you need to tweak your unique constraint (like allowing nulls, or only applying it to certain user types), follow these steps:

1. First, drop the existing unique index (check the index name with db.users.getIndexes()):

   db.users.dropIndex("_id_") // Or the name of your custom unique index
   

2. Create the new index with your desired rules. For example:
   • Allow null values but enforce uniqueness for non-null emails:

     db.users.createIndex({email: 1}, {unique: true, sparse: true})
     

   • Only enforce uniqueness for tenant type users:

     db.users.createIndex({email: 1}, {
       unique: true,
       partialFilterExpression: {type: "tenant"}
     })
     

Key Things to Keep in Mind #

• Check for duplicates first: Before creating a new unique index, run this query to make sure there are no duplicate values in the target field—otherwise the index creation will fail:

  db.users.aggregate([
    {$group: {_id: "$email", count: {$sum: 1}}},
    {$match: {count: {$gt: 1}}}
  ])
  

• Mongoose users: If you’re using Mongoose, update your schema to reflect the new unique key, then run usersSchema.syncIndexes() to sync your schema with the database indexes. Avoid relying on autoIndex: true in production—create indexes manually for better control.
• Performance: Unique indexes do add a small overhead on writes, but it’s negligible for most use cases. Just make sure you’re indexing fields that make sense for your query patterns too.

内容的提问来源于stack exchange，提问作者torbenrudgaard