MGO 设计调优。

#MGO 设计调优。 > 真的是那句话，不是你不行，知识你不了解。而已。

1. 肯定是不能加两个索引了。
   1. 索引的代价实在是太大了，不但占用内存还还大量损失查询性能，真心不能忍耐啊。
2. 设计的时候DBRef肯定是需要的，直接用有意义的ID查询肯定是性能最好的。
3. 控制key的数量肯定是必须的。比如说用户数量就是key的数量这就够了。别整那么多。collection不然损失性能。
   1. 如果真的想控制数量的话，那么数据关联肯定是十分必须的。

4. 流量控制肯定也是必须的。

   1. 流量的来源在于Find直接返回所有查询结果。卧槽。直接吃掉所有流量。
   2. 直接用FindOne 避免查询多个结果回来肯定是必须的

   3. FindOne就够了吗？我确实遇到这个坑了。在博文中已经提到关于这种情况适用filter的方法了。直接参考就OK了。

      FindOne({_id:xxx},{Items:{"$slice":[3,1]}})
      

      虽然适用了这种方法来设计，使得查询结果减少流量降低了。但是依然存在问题 1. 一定更要注意，不能直接dbref因为slice不好加啊。可以用过顺序id加分页，或者算时间。233 很实用，典型的用空间换时间。

      db.user.findOne({user_id:2}, {"book.price":1,"book.price.":{$slice:[-10,4]}})
      
      解释下其含义哈：
      1. user集合
      2. user.book.price 表示用户拥有书籍， 书籍呢有很多价格列表
      3. 注意红色字体  "book.price." 末尾必须有个点
      4. 查找价格列表里的4条数据， 从右边第10个位置开始便宜
      

   但是也有不同的语法说明，到时候试试吧。

5. update 要做精细修改。

  比如Update({_id:xxx},{$set:{"Items.3.Item.Health":38}});//修改第三把武器的健康值

至于一次修改和批量修改，MongoDB默认100ms flush一次(2.x),只要两次修改比较贴近,被一起保存的可能性很高。

上面这些是引用别人说的话,还是全要直接精细修改，然后数据库会自动一起修改的，性能不成问题

1. 最后几点注意
   1. 控制io（系统吞吐）这事整个系统的核心，也是系统性能的核心。
   2. 控制内存（不要让index膨胀）
   3. 控制index个数，
   4. 控制key的个数
   5. CPU控制不要让js做大量的计算，能迁移到客户端的计算就迁移到客户端，让他们算完之后在通讯
   6. 第一个性能不够的估计是硬盘，可以通过RAID或者企业级SSD搞定整个问题。

Golang MGO驱动使用

ref1

ref2