mongodb不支持按月分表，需通过集合命名（如logs_2024_04）+应用层路由+定时脚本建索引模拟；ttl索引仅异步删过期文档，不解决查询性能、集合膨胀或归档隔离问题。
MongoDB 本身不支持“按月分表”这种关系型数据库的模式，也没有传统意义上的“分表”概念；所谓“按月分表”，实际是通过集合命名（如 logs_2024_04、logs_2024_05）+ 应用层路由 + 自动化索引维护来模拟。TTL 索引不能替代分表，它只负责自动删除过期文档，不解决查询性能或集合膨胀问题。
为什么不能靠 TTL 实现“按月分表”
TTL 索引（expireAfterSeconds）只对单个字段（通常是 createdAt 或 _ts）生效，它让 MongoDB 后台线程定期扫描并删除过期文档——但所有文档仍留在同一个集合里。这意味着：
- 集合持续增长，B-tree 索引体积变大，查询
logs.find({month: "2024-04"})依然要全集合扫描（除非你额外建了month索引） - 无法实现真正的“按月归档隔离”，比如把 2023 年数据迁到低频存储、或对某月集合单独做
compact - TTL 删除是异步且不可控的（延迟可达 60 秒），不满足精确到月的生命周期管理需求
如何用集合命名 + 脚本实现按月分表索引管理
核心思路：应用写入时根据当前时间决定写入哪个集合（如 events_2024_05），再由定时脚本为“下个月”的集合提前创建必要索引，避免写入时触发同步建索引阻塞。
实操建议：
- 使用 ISO 格式命名集合，如
events_2024_05，便于排序和正则匹配 - 脚本用 Node.js 或 Python（推荐 PyMongo）编写，每天凌晨运行一次
- 先计算下个月标识：
next_month = (datetime.now().replace(day=1) + timedelta(days=32)).replace(day=1)→ 得到2024-06 - 拼出集合名：
collection_name = f"events_{next_month.year}_{next_month.month:02d}" - 调用
db.getCollection(collection_name).createIndex({timestamp: 1})，并加{background: true}参数防止阻塞 - 检查是否已存在同名索引（用
getIndexes()），避免重复创建
常见错误：索引没生效或建索引失败
现象：新集合写入量突增，查询变慢，explain() 显示 stage: COLLSCAN。
原因与对策：
-
createIndex调用后没等完成就退出脚本 → 加await（Node.js）或acknowledge=True（PyMongo），或查db.currentOp({secs_running: {$gt: 10}})确认后台任务状态 - 权限不足：执行脚本的用户需有
createIndexaction 权限，最小角色为dbAdmin - 字段类型不一致：如果应用偶尔写入
timestamp: "2024-05-01"（字符串），而索引建在timestamp: 1上，会导致部分文档无法被高效命中 → 写入前统一转为ISODate - 忘记为复合查询建组合索引：比如常查
{service: "api", timestamp: {$gte: ...}}，应建{service: 1, timestamp: 1}，而非两个单字段索引
真正需要关注的边界点
集合名长度不能超 64 字节（含下划线和数字），events_2024_12 是安全的，但 user_activity_logs_archive_shard_2024_05 可能截断；另外，MongoDB 5.0+ 支持通配符索引，但仅适用于字段名动态的场景（如 metrics.cpu.*），对“按月分集合”无帮助——别误用。
