1. 儲存引擎型別

• Myisam 速度快，響應快。表級鎖是致命問題。
• Innodb 目前主流儲存引擎
• 行級鎖
• 務必注意影響結果集的定義是什麼
• 行級鎖會帶來更新的額外開銷，但是通常情況下是值得的。
• 事務提交
• 對i/o效率提升的考慮
• 對安全性的考慮
• HEAP 記憶體引擎
• 頻繁更新和海量讀取情況下仍會存在鎖定狀況

2. 記憶體使用考量

• 理論上，記憶體越大，越多資料讀取發生在記憶體，效率越高
• 要考慮到現實的硬體資源和瓶頸分佈
• 學會理解熱點資料，並將熱點資料儘可能記憶體化
• 所謂熱點資料，就是最多被訪問的資料。
• 通常資料庫訪問是不平均的，少數資料被頻繁讀寫，而更多資料鮮有讀寫。
• 學會制定不同的熱點資料規則，並測算指標。
• 熱點資料規模，理論上，熱點資料越少越好，這樣可以更好的滿足業務的增長趨勢。
• 響應滿足度，對響應的滿足率越高越好。
• 比如依據最後更新時間，總訪問量，回訪次數等指標定義熱點資料，並測算不同定義模式下的熱點資料規模

3. 效能與安全性考量

• 資料提交方式
• innodb_flush_log_at_trx_commit = 1 每次自動提交，安全性高，i/o壓力大
• innodb_flush_log_at_trx_commit = 2每秒自動提交，安全性略有影響，i/o承載強。
• 日誌同步
• Sync-binlog =1 每條自動更新，安全性高，i/o壓力大
• Sync-binlog = 0 根據快取設定情況自動更新，存在丟失資料和同步延遲風險，i/o承載力強。
• 效能與安全本身存在相悖的情況，需要在業務訴求層面決定取捨
• 學會區分什麼場合側重效能，什麼場合側重安全
• 學會將不同安全等級的資料庫用不同策略管理

4. 儲存壓力優化

• 順序讀寫效能遠高於隨機讀寫
• 日誌類資料可以使用順序讀寫方式進行
• 將順序寫資料和隨機讀寫資料分成不同的物理磁碟，有助於i/o壓力的疏解，前提是，你確信你的i/o壓力主要來自於可順序寫操作（因隨機讀寫干擾導致不能順序寫，但是確實可以用順序寫方式進行的i/o操作）。

5. 運維監控體系

• 系統監控
  • 伺服器資源監控
    • Cpu, 記憶體，硬碟空間，i/o壓力
    • 設定閾值報警
  • 伺服器流量監控
    • 外網流量，內網流量
    • 設定閾值報警
  • 連線狀態監控
    • Show processlist 設定閾值，每分鐘監測，超過閾值記錄
  • 應用監控
    • 慢查詢監控
      • 慢查詢日誌
      • 如果存在多臺資料庫伺服器，應有彙總查閱機制。
    • 請求錯誤監控
      • 高頻繁應用中，會出現偶發性資料庫連線錯誤或執行錯誤，將錯誤資訊記錄到日誌，檢視每日的比例變化。
      • 偶發性錯誤，如果數量極少，可以不用處理，但是需時常監控其趨勢。
      • 會存在惡意輸入內容，輸入邊界限定缺乏導致執行出錯，需基於此防止惡意入侵探測行為。
    • 微慢查詢監控
      • 高併發環境裡，超過01秒的查詢請求都應該關注一下。
    • 頻繁度監控
      • 寫操作，基於binlog，定期分析。
      • 讀操作，在前端db封裝程式碼中增加抽樣日誌，並輸出執行時間。
      • 分析請求頻繁度是開發架構 進一步優化的基礎
      • 最好的優化就是減少請求次數！
    • 總結：
      • 監控與資料分析是一切優化的基礎。
      • 沒有運營資料監測就不要妄談優化！
      • 監控要注意不要產生太多額外的負載，不要因監控帶來太多額外系統開銷

想了解更多前端培訓開發技術知識，請關注我！

文章轉載連結：http://www.atguigu.com/jsfx/1477.html