3.??Mysql 運維優化

3.1.?存儲引擎類型

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

3.2.?內存使用考量

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

3.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承載力強。
• 性能與安全本身存在相悖的情況，需要在業務訴求層面決定取舍
  • 學會區分什么場合側重性能，什么場合側重安全
  • 學會將不同安全等級的數據庫用不同策略管理

3.4.?存儲壓力優化

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

3.5.?運維監控體系

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