最近做了乙個搜尋介面的優化，反覆壓測了四次，終於達到要求了，記錄一下，晚上加個雞腿?
業務邏輯
從opensearch中檢索出資料，然後各種填充組裝資料，最後返回
邏輯看似很簡單，當初我也是這樣認為的，於是預估5天完成，最後前前後後開發、聯調、改bug直到上線差不多花了10天（當然這10天並不是只做這一件事情）
複雜在於影響返回結構的因素很多，排除問題需要檢查配置、檢查資料庫、檢查快取、檢查opensearch、檢查**
言歸正傳，不管邏輯有多複雜，都不是你逃避問題的介面，更不是你不去優化的理由，這不是本文的重點，優化過程才是
第一次壓測
慘不忍睹，平均響應時間150ms，而且在這次壓測過程中還發現其它的問題，後台報錯，經查是opensearch每秒查詢次數限制
優化**與配置
1、修改opensearch配置，並且將壓測環境中的opensearch連線位址改為內網位址
2、將**中迴圈查詢快取的地方改為一次性批量查詢返回
3、和相關同學確認後去掉專案中無用的**
第二次壓測
雖然優化了**，修改了配置，但是情況更糟糕了，而且還改出了新的問題
當時，反覆檢查了**，確定查詢快取的次數已經是最少了，而且連線線程池相關引數也調到乙個相對較大且合理的值了
如果，再壓測還是無法達到要求的話，只有出最後一招了：快取結果集
第三次壓測
總算符合要求了，併發60的時候響應時間達到32ms，而我又發現了新的優化點
介面中居然還有查資料庫的操作，這可不能忍，排查之後去掉了一些不必要的依賴
成長學會了使用redistemplate的executepipelined進行redis批量查詢
針對本次優化的總結
1、一定要絕對避免迴圈查資料庫和快取（ps：迴圈裡面就不能有查詢快取，更不能有查詢資料庫的操作，因為迴圈的次數沒法控制）
2、對於api介面的話，一般都是直接查快取的，沒有查資料庫的
3、多用批量查詢，少用單條查詢，盡量一次查出來
4、對於使用阿里雲，要留意一下相應產品的配置，該花的錢還是得花，同時，千萬要記得正式環境中使用相應產品的內網位址
5、注意連線池大小（包括資料庫連線池、redis快取連線池、執行緒池）
6、壓測的機器上不要部署其它的服務，只跑待壓測的服務，避免受其它專案影響；對於線上環境，最好一台機器上只部署乙個重要的服務
7、沒有用的以及被注釋掉的**，沒有用的依賴最好及時清理掉
8、集群自不用說
9、一些監控類的工具工具可以幫助我們更好的定位問題，比如鏈路跟蹤，這次專案中使用了pinpoint
10、如果技術上優化的空間已經非常小了，可以試著從業務上著手，用實際的資料說話，可以從日常的訪問量，歷史訪問量資料來說服測試
12、關鍵的地方一定要多加點兒日誌，方便以後排除問題，因為排查線上問題最主要還是靠日誌
記一次SQL優化
問題發生在關聯主表a 4w資料量 和副表b 4w資料量 關聯欄位都是openid 當時用的是 left join 直接跑sql，卡死 伺服器也是差 優化1 改left join 為join，兩者區別就是left join查詢時已主表為依據，該是幾條就幾條 就算副表沒有關聯的資料 join如果副表沒有...
記一次oracle 優化過程
可能很多大牛都知道這個方法，但我是頭回遇到，因為專案原因，要寫很多查詢sql，對速度有要求，所以很注重sql語句的優化。像使用left join 速度會快一些等等一些算是比較常見的方法吧。近兩天做自測時發現了乙個問題，同樣一條語句，加了乙個條件竟然速度慢了那麼多，本身是乙個求彙總的sql語句，查全部...
記一次MySQL索引優化
兩張表是主 check drawings 從 check drawings img 關係。check drawings，主表資料 3591條。select count from check drawings 3591 check drawings img，從表資料107203條，資料量並不大，從表通...