修改字段类型后查询变慢是因为索引按原始BSON类型构建，类型变更导致IXSCAN消失、退化为COLLSCAN；需先删旧索引、更新数据、再建新索引，schemaValidation仅校验新写入文档，不修复存量数据或重建索引。
修改字段类型后查询变慢，explain() 显示 IXSCAN 消失了
因为 MongoDB 的索引是按字段原始 BSON 类型严格构建的。当你用 $set 把一个 string 改成 int（比如 {"status": "1"} → {"status": 1}），旧索引项仍按字符串编码存储，新值无法命中——索引条目和文档实际值类型不匹配，查询引擎只能退化为全表扫描（COLLSCAN）。
实操建议：
- 改类型前先确认该字段是否被任何索引覆盖：运行
db.collection.getIndexes()，检查key中是否含目标字段 - 若已建索引，不要直接批量更新类型；应先
dropIndex()，再更新数据，最后用新类型重建索引 - 对复合索引更敏感：比如索引
{status: 1, createdAt: -1}，只要status类型变动，整个索引失效，哪怕createdAt没变
开启 schemaValidation 能防止字段类型混乱吗？
能，但仅限于新写入或修改的文档——它不修正存量数据，也不自动重建索引。MongoDB 的模式校验（通过 validator + validationAction）只在 insert 或 update 时做类型检查，属于“守门员”，不是“清洁工”。
常见错误现象：开了校验后，find({status: 1}) 还是慢，explain() 仍显示 COLLSCAN——因为历史数据里混着 "status": "1" 和 "status": 1，索引无法统一服务两种类型。
使用场景与参数差异：
-
validationLevel: "strict"（默认）：只校验新写入/更新的文档 -
validationLevel: "moderate"：校验所有更新操作，但upsert: true且匹配不到时，插入的新文档仍可能绕过校验 - 必须配合
validationAction: "error"才会拒绝非法写入；设为"warn"只记日志，毫无约束力
collMod 修改字段类型时，索引真的会自动刷新吗？
不会。collMod 命令本身不支持修改字段类型，它只用于调整集合选项（如 validationLevel、indexOptionDefaults）。网上有些教程误把 collMod 当作类型迁移工具，这是典型误解。
真正需要的是数据迁移流程：
- 用
db.collection.updateMany()批量转换字段类型（注意：需确保所有匹配文档都能安全转型，比如空字符串""转NumberInt(0)会失败） - 执行前用
db.collection.find({status: {$type: "string"}}).limit(5)抽样验证目标数据分布 - 更新后立刻运行
db.collection.dropIndex({status: 1})，再createIndex({status: 1})—— 不要依赖“索引自适应”
性能影响很实在：在千万级集合上，边查边改类型（如用 $convert 在聚合中临时转）会导致每次查询都做运行时类型判断，CPU 升高 30%+，且无法利用索引。
为什么加了 $jsonSchema 校验，索引还是没生效？
因为校验规则和索引是两套独立机制。你写 {"status": {"type": "integer"}}，只是告诉 MongoDB “以后只收整数”，但它不会主动把磁盘上存着的字符串 "200" 改成 200，也不会通知已有索引“请重新按整数排序重建”。索引结构在创建那一刻就固化了。
容易被忽略的关键点：
- 索引键的比较逻辑依赖底层 BSON 类型顺序（例如
stringint），混合类型会让范围查询（{$gt: 100}）结果不可靠 - 唯一索引（
unique: true）在类型混存时可能意外报错：字符串"1"和数字1被视为不同值，但排序位置接近，引发边界 case - 时间戳字段最危险：把
ISODate("...")错存成字符串，不仅索引失效，连$dateToString都会报错
真正稳的做法，是在应用层写入前做类型归一，而不是指望数据库事后补救。
