如果面试官问怎么直接整合成一个文档呢？
采用的是懒惰的、渐进式的整合方案。如果我先查询A文档之后发现A文档还没有嵌入B文档，那么就查询B文档，嵌入进A文档之后，直接更新A文档。在更新A文档的时候，要采用乐观锁策略，也就是在更新的条件里，加上A文档不包含B文档这个条件。
这个业务有一个好处是，没有直接更新B文档的场景，都是通过A来操作B文档，所以不需要考虑其他的并发问题
这种懒惰更新策略里的最后一步更新动作，实际上就是一个乐观锁。所以也可以尝试把话题引导到乐观锁上。
不过，嵌入整个文档是很罕见的优化手段。更加常见的是嵌入部分字段，也叫做冗余字段。这种优化手段在关系型数据库里也很常见，比如A经常使用B的某几个字段，那么就可以在A里面冗余一份。但是这种冗余的方案会有比较严重的数据一致性问题，只有在你能够容忍这种数据不一致的时候，才可以应用这个方案。
在现实中最常见的场景就是在别的模块的文档里冗余用户的昵称、头像，这样可以避免再次去用户文档里查询昵称或头像。毕竟这两个在很多时候都不是什么关键字段。
操作系统优化
前面基本都是查询本身的优化，也可以准备一些操作系统优化的点。
内存优化
在MongoDB里，索引对性能的影响很大，所以应该尽可能保证有足够的物理内存来放所有的索引。
swap
同样需要避免触发交换，可以调小vm.swappiness 这个参数
