MongoDB不支持外键语法和数据库层参照完整性，需应用层模拟：插入前校验父文档存在、删除父文档时清理子文档、更新父键时同步子文档；可用$lookup查询关联数据，事务保障写一致性，但需建索引防性能问题，并自行处理null及软删除逻辑。
MySQL外键语法不能直接用在MongoDB里
MongoDB没有FOREIGN KEY关键字，也不支持数据库层的强制参照完整性校验。任何试图照搬MySQL的CREATE TABLE ... FOREIGN KEY语句都会报错：unrecognized field 'foreignKeys'或类似语法错误。这不是配置问题，而是引擎层面不提供该能力。
应用层模拟外键要解决三个核心动作
所谓“模拟”，本质是把原本由数据库自动完成的三件事，拆出来由代码显式控制：
- 插入子文档前，先查父文档是否存在（例如插入
orders前查users中_id是否匹配） - 删除父文档时，主动清理所有引用它的子文档（比如删
users某条记录，就得遍历orders里user_id字段匹配的文档） - 更新父文档主键（如
_id）时，同步更新所有子文档中的对应字段——但注意：MongoDB默认不允许修改_id，所以实际更常见的是更新业务字段（如email），此时需额外维护反向索引或靠应用逻辑兜底
用$lookup和事务替代部分外键场景
如果只是查询时需要关联数据，$lookup足够轻量；但如果涉及写一致性，必须用事务包裹多集合操作：
db.session.startTransaction();
try {
const user = db.users.insertOne({ name: "Alice" });
db.orders.insertOne({ user_id: user.insertedId, amount: 99.99 });
db.session.commitTransaction();
} catch (e) {
db.session.abortTransaction();
}
注意两点：session必须显式开启，且所有操作需在同一分片上（跨分片事务在4.4+支持但有严格限制）；事务不能替代外键的实时约束——它只保证“这一批操作要么全成功、要么全失败”，不阻止其他客户端绕过事务直接写orders。
最容易被忽略的其实是索引和空值处理
即使手动校验了外键存在性，没建索引会导致find({ user_id: ObjectId(...) })变成全表扫描，尤其在orders量大时拖垮性能。务必对所有外键字段建索引：
db.orders.createIndex({ user_id: 1 })
另外，MongoDB允许user_id: null或缺失字段，这和SQL里FOREIGN KEY ... ON DELETE SET NULL不同——null在这里只是普通值，不会触发任何级联行为。如果业务需要“软删除”语义，得靠应用层约定字段（如is_deleted: true）并统一过滤，而不是依赖数据库机制。
