不该直接存成大文档应将每次点击作为独立文档存储精简字段、建合理索引并用唯一复合索引实现去重配合覆盖索引优化聚合查询按需预聚合。点击事件该不该直接存成大文档别把每次点击都塞进一个嵌套数组里——这是最典型的“日志当文档”误用。MongoDB 单文档上限 64MB但更现实的瓶颈是一旦 clicks 数组涨到几千条$push 写入会变慢$elemMatch 查询变卡连 db.collection.stats() 都可能因文档膨胀而失真。真正该做的是把「点击」当作原子事件独立建模每个点击事件存为一条独立文档字段精简 { ad_id: ObjectId, user_id: u_123, timestamp: ISODate(...), ip: 192.168.1.1, ua_hash: a1b2c3... }去掉冗余字段如完整 user_agent 字符串改用哈希值 索引省空间也提速避免在广告文档里用 clicks: [...] 嵌入——这会让广告文档随时间不可控膨胀且无法对“过去24小时所有点击”做高效聚合如何低成本实现点击去重去重不是靠应用层查一遍再写而是靠 MongoDB 原生约束和结构设计。核心思路把“用户 × 广告 × 时间窗口”变成唯一键让数据库自己拦住重复。实操上分两步走定义自然去重粒度比如“同一用户 15 分钟内对同一广告的多次点击只记一次”那么复合唯一索引就是db.clicks.createIndex({ ad_id: 1, user_id: 1, window_start: 1 }, { unique: true })其中 window_start 是 timestamp 向下取整到最近 15 分钟如 new Date(Math.floor(ts.getTime() / 900000) * 900000)写入时用 insertOne 而非 updateOne upsert配合 writeConcern: majority失败即说明已存在无需额外查切忌用 find().count() 判断是否存在——高并发下必然漏判且性能崩盘聚合查询慢先检查索引覆盖和时间范围广告后台最常跑的是“某广告近7天点击量”或“某渠道各广告 CTR”这类聚合慢90% 不是管道写得差而是没让索引扛住过滤和排序。 跃问 跃问是由阶跃星辰开发的免费AI智能问答助手随时帮你智能搜索、高效阅读、识图理解、和你畅聊感兴趣的话题。