對於程式優化，我一直採取保守的態度，除非萬不得已。但是隨著業務的不斷發展，程式越來越複雜，**越寫越多，優化似乎是終有一天會到來的事情。那麼對於乙個典型的後台服務介面，我們可以從那些方面入手進行優化呢？
垂直拆分可以簡單理解為微服務化，把乙個大而複雜的服務拆分成多個相互獨立，職能單一的服務，單獨部署。 更細粒度拆分的好處是，能對某個具體的微服務進行特殊優化，以最大的投入產出比來解決整個服務的效能。 垂直拆分還有乙個好處是，對於非必須的介面，可以很方便的進行降級處理，把壞影響隔離到核心邏輯外部。 最容易想到的優化辦法是把某個對整體效能有決定性影響的微服務介面進行水平擴容。
這裡說的水平拆分一定不是把乙個介面部署更多份，因為這樣只能解決介面的容量問題，但是不能減少介面的響應時間。 水平拆分可以簡單理解成mapreduce模型，把整個計算邏輯或者資料平均分配到集群中的n個伺服器去，然後由一台機器去併發呼叫並做結果合併。 理論上這種方式能把響應減少到的時間。
乙個有著複雜邏輯或者大量計算資料的介面，能對整個結果進行快取再好不過了。快取針對不同的場景會有多種策略，對於有大量併發請求的場景， 推薦乙個方案：一種基於「哨兵」的分布式快取設計，不會有損失第乙個使用者，也不會有定時更新快取的額外開銷。
本地快取有兩種場景，對於類似字典型別的資料，可以靜態化後放入記憶體，定時去重新整理或者採用通知機制去更新。
還有一種場景是用threadlocal快取重複內部計算與重複的物件建立； 對於鏈路比較長或者迴圈比較深的介面，threadlocal減少重複計算和物件建立，從而降低rt和節約記憶體。
類似於發訊息，寫日誌，更新快取等不會影響介面準確性的非核心流程，可以採用非同步方式進行處理，不阻塞主計算邏輯處理。
如果進行水平拆分後，併發呼叫io較大，可以考慮換成內部併發解決io問題。如果內部併發涉及到每個執行緒更新同乙個集合資料，不用忘了使用執行緒安全的集合。 這裡有乙個併發更新hashmap的case：併發環境下hashmap引起full gc排查。
mysql 優化策略 mysql的優化策略有哪些
第一 優化你的sql和索引 1.善用explain，看看自己寫的sql到底要涉及到多少表，多少行，使用了那些索引，根據這些資訊適當的建立索引 2.善用不同的儲存引擎，mysql有多種不同的儲存引擎，innodb，aria，memory根據需要給不同的表選擇不同的儲存引擎，比如要支援transacti...
not in 優化策略
總結們在csdn社群上對於not in的優化策略，整理如下，備查。select from emp where emp no not in select emp no from emp bill 要求用兩種 sql寫法優化上面 sql。方法一 select from emp a where notex...
Oracle 優化策略
1.普通表轉分割槽表 大表 2g，多於1000萬條記錄 2.索引 減少非索引掃瞄 建立索引在約束條件列，選擇性高列，被驅動表 內錶 連線列 驅動表的連線列不一定 結果集在總行數的2 4 應建索引 編號，日期，外來鍵 函式索引 query rewrite integrity trusted,query...