一次性能优化带来的反思

项目中存在问题

资产变更通知模块，用户在配置了变更通知之后，系统会根据该表的血缘信息生成一个附件，附件内容为该表所影响到的下游数据信息。
因为公司的数据体量大，表的血缘信息也比较复杂，某一张表的信息影响到的下游都有十万张表。因此在生产Excel的过程，用户需要等待十多分钟。

分析以及优化

因为某一张表的血缘信息时调用其他服务的数据得到的，返回的数量级都是以万为单位计算。
例如：其他微服务返回五万条数据，我拿着这五万条数据进行查询mysql数据库，补充信息，生成Excel。分析这个Excel生成过程，耗时地方，在下方罗列出来

• 调用其他微服务返回这五万条数据耗时。
• 查询mysql数据库，封装填充Excel的数据 list。
• 对查询出来的 list 进行进一步的补充。（当时直接忽略）

我的分析

• 使用postman直接测试对方提供的接口，结果很快。
• 我就想当然的认为那就是查询mysql数据库耗时，因为数据量比较大。

我的优化

把返回的数据分批查询，每次查询一千条数据，最终把查询数据放入list集合。

注：因为开发测试都是没有数据，我们只能去灰度验证，大佬建议我把每个阶段的耗时打印出来，因为我比较自负，认为一定是那个查询数据库操作耗时，因此我也只是打印了整体过程的耗时。

结果

优化前后耗时基本一样

---

在别人的帮助下开始优化

分析定位：

• 调用其他接口数据耗时测试
• 查询mysql封装Excel的数据list
• Excel有一列是用户信息，只能通过代码额外补充，不能通过第二步查询数据库得到。
  程序慢的原因主要在第三步：补充用户信息，因为补充用户信息，做了查询数据库的操作，而且是在循环中查询数据库。

启示

态度

• 态度问题，自己总是认为如果开发，测试有数据我也可以定位到问题，外部环境固然有影响，但是要明白，外部环境就是这样，有可能还差。难道就不能定位问题，解决问题了吗？必然是可以的，这是一个态度问题。
• 不能想当然认为，要认真分析问题，解决问题。

技术层面

• SQL 层面的优化
• 代码逻辑优化
• 循环中之中不查数据库，在循环之前要准备好所需数据