不推荐按天建独立集合。手动分集合会显著增加应用层复杂度，而MongoDB的shard key和TTL索引已足够支撑亿级消息场景，强行按天切集合易在跨日查询、归档、权限管理上出问题。
消息集合要不要按天建独立集合（如 messages_20240520）？
不推荐。手动分集合看似能控制单集合大小，但会显著增加应用层复杂度：路由逻辑、索引同步、备份恢复、聚合查询都得额外处理。MongoDB 的 shard key 和 TTL 索引已足够支撑亿级消息场景，强行按天切集合反而容易在跨日查询、归档、权限管理上翻车。
实操建议：
- 用单集合
messages，靠created_at字段 + TTL 索引自动过期旧数据 - 若读写热点集中在最近 7 天，可对
created_at建时间范围分片（shard key 为{created_at: 1}），但需确保写入时间单调递增，避免 chunk 拆分不均 - 绝对不要用日期字符串拼接集合名——驱动不支持动态集合名批量操作，ORM 映射极易出错
find() 分页时为什么游标失效或漏数据？
因为聊天消息天然高并发写入，skip/limit 分页在插入新消息时会导致偏移错位；而基于 _id 或 created_at 的「游标分页」若没处理好边界条件，也会跳过或重复某条消息。
实操建议：
- 永远用游标分页，例如上一页最后一条是
{_id: ObjectId("..."), created_at: ISODate("...")}，下一页查：db.messages.find({created_at: {$lt: lastMsg.created_at}, _id: {$lt: lastMsg._id}}).sort({created_at: -1, _id: -1}).limit(20) - 复合排序必须严格匹配索引字段顺序，建索引：
db.messages.createIndex({created_at: -1, _id: -1}) - 避免用
$gte+$lt区间查“某天全部消息”再分页——这本质是全量扫描，响应随数据增长线性变慢
如何让“加载更多”在滚动时既快又准？
关键不是查得快，而是让每次请求返回的文档尽可能少走磁盘、少排序、不阻塞写入。默认的 sort + limit 在大 offset 下性能断崖下跌，尤其当 created_at 有大量重复值时（比如毫秒级时间戳+高并发写入）。
实操建议：
- 把
_id当作隐式时间戳用：ObjectId 本身前 4 字节是秒级时间戳，升序即时间顺序，降序即倒序，天然去重 - 查询语句里强制带上
projection只取必要字段，比如：{content: 1, sender_id: 1, created_at: 1, _id: 1}，避免传输和序列化整条消息 - 客户端缓存上一页的最后
_id和created_at，服务端校验二者是否一致——防止因时钟不同步或写入延迟导致游标漂移
TTL 索引删消息会不会卡住写入？
会，但只在极端情况下。TTL 删除是后台线程异步执行的，一般不影响写入吞吐。但如果设置了极短的过期时间（比如 1 小时），且每天新增消息量巨大，删除压力集中，可能拖慢 mongod 的后台任务调度。
实操建议：
- TTL 字段必须是
Date类型，且索引唯一：db.messages.createIndex({expires_at: 1}, {expireAfterSeconds: 0}) - 别用
created_at直接做 TTL 字段——万一要查“3 天前未读消息”，它就被删了；单独加expires_at字段，按业务策略写入（如“7 天后过期”就设为created_at + 7*24*3600） - 监控
metrics.ttl.deletedDocuments指标，如果每秒删除量持续 > 1000，考虑拆成多阶段归档：先 TTL 到冷表，再定时批删
真正难的不是分桶或分页语法，而是让时间字段在写入、查询、过期三个环节保持语义一致——created_at 是业务时间，_id 是写入顺序锚点，expires_at 是生命周期终点，三者不能混用，也不能靠客户端拼凑。
