業務場景：
也測的業務，如上圖，通過捕獲業務的涉及的接口如下：
查詢接口耗時大於7s,已經是非常的慢
經驗提示：
一般接口響應時間慢的問題，最簡單的方式就是監控接口相關的sql是否存在問題
開啟mysql的慢查詢監控：
這兩個sql加起來，大致等於接口的響應時間，證明問題猜的沒錯，問題就是這兩個sql查詢慢導致的問題7s左右
驗證sql是否有問題：
查看這個表的執行計划：
發現d表走了全表掃描，直接查詢60多萬的數據，肯定會很慢
由於d表已經存在orgId存在索引，考慮給o表添加索引
ALTER table t_debt_overview ADD INDEX IDX_orgId(`orgId`);
現在掃描的行數減少了，只掃描必要的4999行
另外的sql問題也解決了
不用壓測，這個性能問題就可以解決
總結：所以在性能測試的過程中，不一定非要執行壓測才能發現性能問題，一般在性能壓測前，簡單的執行一下業務，看看是否存在耗時比較長的業務，提前優化，提高壓測的效率