一次关于mongodb性能踩坑的总结

刘伟

发现性能问题
　　上一次导入数据后，发现系统十分的卡顿，但是才仅仅1000多条数据而已，怎么会让系统变得如何的卡顿呢?于是我开始走在排查系统卡顿的原因的道路上。
　　首先，先定位问题是出现在前端上还是后端上。打开浏览器，输入localhost:7000, 然后F12打开netword。启动后端项目，查看log。切换回浏览器，右键刷新。结果发现好多些问题:

• 请求发送的个数比较多。
  
• 后端每个接口的响应时间都比较长，都超过了1s，这明显有问题。
  
• 前端很多请求从: 发送请求到页面渲染成功所需要的时间大于了10S(发送请求时间+后端接口响应时间+下载资源时间，即回传数据时间+页面渲染时间)。
  

　　从上面这几个现象可以看出:

• 后端有明显的问题。
  
• 前端暂时没有什么问题。
  

　　好好分析一下，为什么后端每个接口的响应时间都会超过1s，mongodb是出了名的速度快，一般查询数据就几十ms，普通查询也不会超过300ms。但是看到的接口响应时间却是超过了1s，有的还是明显3，4s。
　　苦苦冥想，细细推测，思来想去，都不知道是怎么回事，最后只有采用删代码的方式来定位问题了。
　　当删除类似于下面的代码的时候
　　

Schema.virtual('affixes', {　　ref: 'Affix',
　　localField: '_id',
　　foreignField: 'businessId',
　　
});
　　

　　这个时候，发现后端接口的响应时间正常了，可以判断，这段代码起到了一定的作用，但是这只是简单的连表查询而已。为什么就导致接口响应时间多那么多呢？
　　我继续分析，进入到controller.js里面，将与表关联查询的代码找出来，终于，我快要发现元凶了，删除这几行代码，ok，同样，响应时间正常了。
　　仔细分析这几行代码，发现了一个很重要的事情: 居然是全表查询！！而且是3张表关联的全表查询！！所以...查询的数据差不多就是这个量: 2000 * 2000 * 2000, 也怪不得为什么响应时间会超出1s了。
　　第一个元凶已经被抓住了。但是我还并不知道为什么前端从请求到渲染成功的时间怎么会超过10s，这简直不能忍。
　　清空network，然后刷新，重新发送请求，可以看见发送了5个左右的请求，而查看后端的log发现其中3个请求都是在做表关联的全表查询，并且reply的时候还是将所有的数据都返回到前端里去了。
　　ok，现在我大概已经知道为什么会有超过10s的响应时间了，下载的数据量也比较大，所以响应时间 = 发送请求时间 + 后端处理时间 + 下载资源时间 + 渲染时间, 由于数据量比较大，所以导致最后的两个时间也不小。
　　现在大概已经都找出了为什么页面会卡顿并且迟缓。原因就是没有做后端分页，系统里用的是前端分页。

性能优化总结

• 查询数据避免多张表关联全表查询。
  
• 先过滤再关联查询，而不是先查询再关联表。
  
• react里多个列表，一定要设置key。
  
• 分页一定不要前端做，因为数据量大了肯定要崩掉的。