在性能優化項目中，我只是一個協助參與的角色，但也正好給了我從外部參看項目運作的機會，需要優化的系統已經是運行了6年的老系統，數據從來沒有做過分離，涉及全庫查詢等致命的優化問題。另外本次項目的業主也希望對優化工作進行指導，造成走了不少彎路，同時由於垂直數據庫技術不足，從外部找了合作伙伴進行深入性能優化研究。
總之這個項目雖小，但具備了複雜項目的各方面的內容，我也將會對這個項目進行初步的分析。
基礎方向
SQL優化
首先要做的就是找出執行慢的SQL或業務模塊，調查SQL的業務邏輯是否存在可優化的空間。
- 我們先做的是根據業務部分給出的緩慢業務，查詢對應的SQL，並在測試環境中模擬運行，並記錄生產環境和測試環境執行響應SQL的時間
- 將最有代表性的SQL（常用業務）的執行計劃列出，並查看索引的執行情況。在本次項目中，發現執行計劃沒有執行設定的索引，這個關鍵問題也是優化的重點方向。
調整表分區
表分區一直是數據庫優化的重要首選。根據業務將表按照特定的字段或特定規則進行分區，能夠大大提升數據庫的性能。但需要注意，分區表將影響數據的插入效率，與建立索引相同，在建立表分區的過程中要分析利弊。
數據量的增加對性能開銷的影響
項目中存在測試環境與生產環境，其數據量級別不同，環境配置也不同，就會造成執行相同的SQL或業務得到相反的結果，故在性能優化的前期，要至少滿足數據量的同步，這樣可以實現具有相同標準的對比。
在項目中的系統，將特定表的數據調整爲相同時，執行效率基本相同，這就證明： - 性能不是造成SQL執行慢的瓶頸
- 數據量的增加會造成緩存的增加，同時效率變換與緩存大小有關，並且和命中率有關。
讀寫分離
由於系統的業務數據量過大，且根據需求要滿足無條件限制的查詢，這樣就勢必造成全表掃描。爲了能夠查詢效率，必須要實現讀寫分離，在業務時間範圍只進行讀操作（對查詢時限要求較低），非業務時間將數據進行同步。
關於業主
本次項目的業主，技術負責人對技術要求極爲苛刻，當然這也是爲了項目能夠順利進行的必要條件，如何才能順應這樣的客戶，時限快速迭代，快速彙報？在項目初期，我們也走了很多彎路。
- 一味的順應只能讓自己變成無頭蒼蠅
- 當出現信任危機的時候，建立信任可能已經是無法挽回的事情
- 溝通頻率要把握清楚，埋頭苦幹也要擡頭看路
以上是我們在於業務溝通和處事時出現的問題，當然問題的源頭也出在開始我們對項目理解不清楚。