业务场景：
也测的业务，如上图，通过捕获业务的涉及的接口如下：
查询接口耗时大于7s,已经是非常的慢
经验提示：
一般接口响应时间慢的问题，最简单的方式就是监控接口相关的sql是否存在问题
开启mysql的慢查询监控：
这两个sql加起来，大致等于接口的响应时间，证明问题猜的没错，问题就是这两个sql查询慢导致的问题7s左右
验证sql是否有问题：
查看这个表的执行计划：
发现d表走了全表扫描，直接查询60多万的数据，肯定会很慢
由于d表已经存在orgId存在索引，考虑给o表添加索引
ALTER table t_debt_overview ADD INDEX IDX_orgId(`orgId`);
现在扫描的行数减少了，只扫描必要的4999行
另外的sql问题也解决了
不用压测，这个性能问题就可以解决
总结：所以在性能测试的过程中，不一定非要执行压测才能发现性能问题，一般在性能压测前，简单的执行一下业务，看看是否存在耗时比较长的业务，提前优化，提高压测的效率