記錄日常代碼延時高的問題

場景1  前端反映，首頁index接口延時過高，幾乎一秒纔有響應

步驟一：定位問題代碼  

因爲該模塊，線上arthas禁用了，沒辦法，老老實實打日誌，定位具體哪裏耗時比較多

發現，接口整體時延在800ms左右，但第一步查詢當日訂單數的時候，就已經花了500多ms了，其他查詢一般都是幾十ms左右，找到問題所在。

步驟二：具體問題分析

看下獲取邏輯，其實就是單純從表裏查詢數據然後走dubbo返回，那就更nice了，sql出問題的概率大，到測試環境看下執行計劃

全表掃，沒走上索引，線上百萬級數據，肯定會比較慢的，再看下錶的索引如何建的。

看了下，所有的查詢，其實都是company_id 單獨查詢，  或者company_id + shop_id 搭配着查詢

步驟三：解決思路

適合建立聯合索引，建好了再看下效果

恢復正常水平，測試環境 300ms左右，線上 100ms以內

步驟四：想一下，是否還有優化空間了！

思考： 問題修復了，從代碼角度 這個接口還有沒有可以優化的地方了？

           接口整體邏輯屬於： index頁面展示不同的數據，分別調用A、B、C接口，返回A、B、C數據返回給前端展示，三個接口之前數據其實互相不干擾。

           現在是同步往下依次調用，其實可以使用countDownLatch或者CyclicBarrier 異步處理，然後塞到響應裏面返回！