mongodb中应使用collmod命令原地修改ttl索引的expireafterseconds值，而非dropindex+createindex重建，因后者会导致过期管理空窗期、锁表及性能抖动；collmod是毫秒级元数据变更，安全高效。
用 collMod 修改已有 TTL 索引的 expireAfterSeconds
MongoDB 不允许直接删除再重建同名 TTL 索引来“更新”过期时间，因为重建会触发全量扫描、可能引发短暂性能抖动，且索引名或字段顺序稍有差异就容易出错。正确做法是调用 collMod 命令原地修改索引属性。
执行前必须确认：该索引已存在，且是单字段日期索引（TTL 不支持复合索引）；目标字段值类型为 Date 或能被自动转为日期的字符串（如 "2026-09-07T14:00:00Z"）。
示例：把集合 logs 中基于 created_at 字段的 TTL 过期时间从 3600 秒改为 7200 秒：
db.runCommand({
collMod: "logs",
index: {
keyPattern: { "created_at": 1 },
expireAfterSeconds: 7200
}
})
常见错误现象：
-
"cannot find index {\"created_at\": 1} for ns mydb.logs"：说明该字段上没有已建索引，需先用createIndex创建 - 返回
"ok": 0且提示"index with pattern ... not found"：keyPattern 必须**完全匹配**原有索引定义（包括字段名大小写、排序方向），不能写成{"created_at": -1}去改一个1的索引 - 修改后文档未按时删除：检查
created_at字段是否为Date类型（typeof doc.created_at === "object"且doc.created_at instanceof Date），字符串格式日期不被 TTL 线程识别
为什么不能用 dropIndex + createIndex 替代
表面看更直观，但实际风险高：
后台 TTL 删除线程依赖索引持续存在。一旦 dropIndex 执行完成、新索引尚未建好之间存在空窗期，新插入的文档将不会被纳入过期管理，直到新索引 ready 并开始扫描——这个间隔可能长达数秒甚至更久，取决于集合大小和负载。
此外：createIndex 是阻塞操作，在大集合上会锁表（WiredTiger 引擎下为“建索引期间禁止写入”），而 collMod 是元数据级变更，毫秒级完成，无锁、无扫描、无中断。
所以除非你明确需要更换 TTL 字段（比如从 created_at 改为 updated_at），否则一律用 collMod。
Azure Cosmos DB for MongoDB 的特殊处理
Cosmos DB 使用系统字段_ts（不可读写）作为 TTL 时间源，行为与原生 MongoDB 不同：
它只支持一种方式设置 TTL：在 _ts 上建索引并指定 expireAfterSeconds，例如：
db.coll.createIndex({"_ts": 1}, {expireAfterSeconds: 300})
但注意：collMod 在 Cosmos DB 中对 _ts 索引的 expireAfterSeconds 修改**无效**——该平台不支持运行时调整系统字段索引的 TTL 值。若需变更，只能删掉旧索引、重建新索引（此时仍存在前述空窗期风险）。
另外，Cosmos DB 支持文档级 TTL 覆盖集合级设置：只要文档含 ttl 字段（int32），其值会替代索引中的 expireAfterSeconds。这属于额外能力，原生 MongoDB 不支持。
验证修改是否生效
别只信命令返回的"ok": 1：
查索引定义是否已更新：
db.logs.getIndexes()
重点关注目标索引对象里的 expireAfterSeconds 值是否为你设的新值。如果还是旧值，说明 collMod 没命中索引（keyPattern 不匹配）或权限不足（需 collMod 权限，非仅 readWrite）。
真正关键的是观察后台线程行为：TTL 清理不是实时的，mongod 默认每 60 秒扫描一次。所以即使索引改了，也要等至少 1–2 分钟再查文档是否开始按新规则消失。别在执行完 collMod 后立刻 find 验证——那只会让你误判失败。
