淺談優化順序

提到sql優化,不要一上來就是加索引,索引增長存儲負荷,下降寫入效率,並且有時候添加了還不定用獲得，因此添加索引不是萬靈藥。也不是惟一手段，如下從開發者角度與數據庫運維角度總結了優化流程，以供你們借鑑。

優化流程:

• 開發角度: sql語句優化 → 第三方優化 → 索引優化 → 模型優化 → 修改功能

• 運維角度: 數據庫配置 → 讀寫分離 → 虛擬機配置 → 物理機配置

---

sql語句優化:

• 檢測sql是否能夠拆分
• 分析sql語句執行計劃,是否須要添加索引
• 樣例:
  • sql語句功能: 查詢某商品全部評論以及評論匹配到的信息
  • sql優化前性能: 數據量達到200萬總量查詢效率極差,具體表如今4核服務器滿cpu運行10分鐘未出結果
• 優化過程:
  1. 語句拆分，先查詢商品全部包含子商品，查詢該子商品全部評論 --> 優化結果60s出結果
  2. 針對該語句查詢字段創建索引 --> 優化結果20s出結果
  3. 更改數據模型，由原來6個表下降到5個表 --> 優化結果1-8秒出結果(達到公司要求)

優缺點: 改動量最小，可是優化程度有限

第三方優化:

• 添加內存數據庫-redis
• 添加全文搜索引擎-elasticsearch
• 添加....
• 樣例:
  • 一個查詢全部數據頁面，每次用戶點都要10s響應，並且點多幾回就會佔用完鏈接池
• 分析緣由：
  • 經過分析瞭解到用戶只是想看最新的數據狀況，極少數會翻頁
• 優化過程
  • 使用redis緩存每一個用戶前幾頁數據 --> 秒出

優缺點: 使用靈活,增長運營成本

索引優化：

• 經常使用優化手段，就再也不多作複述了

模型優化:

• 模型重構,主要是達到查詢減小關聯查詢
• 樣例：
  • 原來咱們查詢購買，經過多表關聯查詢 --> 平均查詢20s
• 優化過程
  • 將購買數據拍平成一張表，直接填寫相關數據，去掉外鍵關聯 --> 秒出

優缺點:影響較大,可極大程度優化

修改功能

• 在前面那些都沒法優化時候就能夠考慮修改功能
• 樣例：
  • 分頁時前端須要數據count來計算中的總頁碼，然而不少時候查詢卡在sql count這裏
• 優化過程
  • 採用相似百度分頁效果，一次顯示10頁頁碼，不足的以實際穩準，在mysql查詢中可經過limit a,b實現該效果，同時能夠配合redis提早緩存其餘分頁數據,即提升了效率,又解決問題

優缺點:改動量最大,可最大程度優化

---

建議：

詳細設計時,應該針對模型進行評審,評審應該從主要功能查詢出發,檢驗模型是否能夠高效支持查詢。

1. 儘可能減小關聯查詢
2. 不拘泥於設計範式

---

若是不知道送女神啥禮物,掃他 ↓↓↓↓

---

• 太忙沒時間挑禮物,或者不知道送什麼?
• 怕買到貴的,或者質量差的?
• 沒事,沒事,ag銀飾爲你解決全部麻煩.
• 本店主營銀飾,接受黃金,鑽戒定製.
• 本店保證,質量優良,價格實惠,童叟無欺,順豐包郵