1. 为什么你的MongoDB总会出现重复数据？

假设你刚接手一个电商项目，用户数据导入后突然发现张三的订单出现了3次。这不仅浪费存储空间，还可能引发统计错误。MongoDB的灵活文档结构就像一把双刃剑——它支持自由的数据格式，但也容易在导入时埋下重复隐患。

典型场景示例：

// 使用mongoimport导入CSV时未指定唯一索引
// 命令行操作（技术栈：MongoDB Shell）
mongoimport --db=shop --collection=users --type=csv --headerline --file=users.csv

此时若CSV中存在_id字段重复或未设置唯一约束，就会直接插入重复文档，就像图书馆没有目录时管理员会把同一本书放三次到书架上。

2. 重复数据的元凶

2.1 无唯一索引的裸奔操作
// 查看当前集合索引状态（技术栈：MongoDB Shell）
db.users.getIndexes()
// 返回空数组表示没有任何索引防护

这相当于让所有访客无需安检直接进入数据中心。当使用insertMany批量插入时，重复数据会轻松溜进数据库。

2.2 ETL工具的配置失误

假设使用Python脚本处理数据：

from pymongo import MongoClient
client = MongoClient()
db = client.shop

def import_data():
    # 假设data是从外部API获取的重复数据
    for record in external_api.get_data(): 
        db.users.insert_one(record)  # 直接暴力插入

这种"来者不拒"的写入方式，就像超市收银员不核对商品条码直接扫码，导致相同商品重复结账。

3. 五步根除重复数据实战

3.1 建立唯一防护盾
// 创建唯一组合索引（技术栈：MongoDB Shell）
db.users.createIndex(
    { "mobile": 1, "email": 1 },
    { unique: true, partialFilterExpression: { mobile: { $exists: true } } }
)

这个索引就像给每个用户装上身份证识别器，当尝试插入相同手机号+邮箱组合时会触发错误。注意partialFilterExpression确保只有包含手机号的文档才受约束。

3.2 聚合框架去重术
// 通过聚合管道识别重复项（技术栈：MongoDB Shell）
const pipeline = [
    { $group: {
        _id: "$mobile",
        dups: { $push: "$_id" },
        count: { $sum: 1 }
    }},
    { $match: { count: { $gt: 1 } }}
];

db.users.aggregate(pipeline).forEach(doc => {
    doc.dups.slice(1).forEach(dupId => {
        db.users.deleteOne({ _id: dupId }) // 保留第一个出现的文档
    })
})

这个操作就像图书馆员用条形码扫描仪找出重复书籍，只保留最早入库的那本。

4. 版本化写入策略

# 使用upsert实现智能更新（技术栈：PyMongo）
from datetime import datetime

def smart_import(user_data):
    update_doc = {
        "$setOnInsert": {  # 只在插入时设置的字段
            "createdAt": datetime.now(),
            "source": "2023_migration"
        },
        "$set": {  # 每次更新都会刷新的字段
            "updatedAt": datetime.now(),
            "address": user_data["address"]
        }
    }
    
    result = db.users.update_one(
        { "mobile": user_data["mobile"] },
        update_doc,
        upsert=True  # 关键参数：存在则更新，不存在则插入
    )
    return result.upserted_id

这种方案就像智能门禁系统：已登记住户刷脸更新信息，新访客自动建档。

5. 关联技术深度解析

BulkWrite API的妙用：

// 批量处理重复数据（技术栈：MongoDB Shell）
const bulkOps = [];
const cursor = db.users.aggregate([...]); // 假设已找到重复数据

cursor.forEach(doc => {
    bulkOps.push({
        updateOne: {
            filter: { _id: doc._id },
            update: { $set: { status: "archived" } } // 标记而不删除
        }
    });
    if(bulkOps.length === 500) {
        db.users.bulkWrite(bulkOps);
        bulkOps = [];
    }
});

// 处理剩余操作
if(bulkOps.length > 0) db.users.bulkWrite(bulkOps);

这种批处理方式就像快递分拣中心的自动化流水线，效率是单条操作的10倍以上。

6. 应用场景全景分析

场景1：跨数据库迁移 当从MySQL迁移用户数据到MongoDB时，由于字段映射错误可能导致username字段重复。此时采用$merge阶段进行条件合并：

// 使用聚合框架的$merge（技术栈：MongoDB 4.2+）
db.mysql_users.aggregate([
    { $project: { 
        username: 1, 
        migratedAt: new Date() 
    }},
    { $merge: {
        into: "mongo_users",
        on: "username",          // 合并依据字段
        whenMatched: "keepExisting",  // 已存在则保留原文档
        whenNotMatched: "insert" 
    }}
])

7. 技术方案优劣对比表

方法 处理速度 数据安全 实现复杂度 适用场景
唯一索引拦截 ★★★★☆ ★★★★☆ ★★☆☆☆ 预防阶段
聚合管道删除 ★★☆☆☆ ★☆☆☆☆ ★★★★☆ 小规模数据
BulkWrite标记 ★★★★☆ ★★★★☆ ★★★☆☆ 需要审计追踪
$merge智能合并 ★★★★★ ★★★★☆ ★★★★☆ 大数据量迁移

8. 血泪教训

  • 索引陷阱：在已存在重复数据的集合上创建唯一索引会直接报错，就像试图给混乱的图书馆建立目录系统前需要先整理书籍
  • 时区刺客：时间类型的字段若未统一时区，可能导致看似不同的时间戳实为同一时间（如UTC+8和UTC+0的差异）
  • 内存杀手：使用$group处理百万级文档时，务必添加allowDiskUse:true参数，避免内存溢出导致进程崩溃

9. 终极解决方案选择树

                       开始处理重复数据
                           │
           ┌───────────────┴───────────────┐
           │                                │
   数据量 < 10万条                 数据量 > 100万条
           │                                │
           ▼                                ▼
 使用聚合管道+脚本删除             采用分片BulkWrite处理
           │                         配合临时索引优化
           ▼                                │
   验证删除结果                     使用$out阶段覆盖写入
           │                                │
           └───────────────┬───────────────┘
                           ▼
                     重建业务唯一索引