3.??Mysql 運(yùn)維優(yōu)化

3.1.?存儲(chǔ)引擎類型

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

3.2.?內(nèi)存使用考量

• 理論上，內(nèi)存越大，越多數(shù)據(jù)讀取發(fā)生在內(nèi)存，效率越高
• 要考慮到現(xiàn)實(shí)的硬件資源和瓶頸分布
• 學(xué)會(huì)理解熱點(diǎn)數(shù)據(jù)，并將熱點(diǎn)數(shù)據(jù)盡可能內(nèi)存化
  • 所謂熱點(diǎn)數(shù)據(jù)，就是最多被訪問(wèn)的數(shù)據(jù)。
  • 通常數(shù)據(jù)庫(kù)訪問(wèn)是不平均的，少數(shù)數(shù)據(jù)被頻繁讀寫，而更多數(shù)據(jù)鮮有讀寫。
  • 學(xué)會(huì)制定不同的熱點(diǎn)數(shù)據(jù)規(guī)則，并測(cè)算指標(biāo)。
    • 熱點(diǎn)數(shù)據(jù)規(guī)模，理論上，熱點(diǎn)數(shù)據(jù)越少越好，這樣可以更好的滿足業(yè)務(wù)的增長(zhǎng)趨勢(shì)。
    • 響應(yīng)滿足度，對(duì)響應(yīng)的滿足率越高越好。
    • 比如依據(jù)最后更新時(shí)間，總訪問(wèn)量，回訪次數(shù)等指標(biāo)定義熱點(diǎn)數(shù)據(jù)，并測(cè)算不同定義模式下的熱點(diǎn)數(shù)據(jù)規(guī)模

3.3.?性能與安全性考量

• 數(shù)據(jù)提交方式
  • innodb_flush_log_at_trx_commit = 1 每次自動(dòng)提交，安全性高，i/o壓力大
  • innodb_flush_log_at_trx_commit = 2每秒自動(dòng)提交，安全性略有影響，i/o承載強(qiáng)。
• 日志同步
  • Sync-binlog =1 每條自動(dòng)更新，安全性高，i/o壓力大
  • Sync-binlog = 0 根據(jù)緩存設(shè)置情況自動(dòng)更新，存在丟失數(shù)據(jù)和同步延遲風(fēng)險(xiǎn)，i/o承載力強(qiáng)。
• 性能與安全本身存在相悖的情況，需要在業(yè)務(wù)訴求層面決定取舍
  • 學(xué)會(huì)區(qū)分什么場(chǎng)合側(cè)重性能，什么場(chǎng)合側(cè)重安全
  • 學(xué)會(huì)將不同安全等級(jí)的數(shù)據(jù)庫(kù)用不同策略管理

3.4.?存儲(chǔ)壓力優(yōu)化

• 順序讀寫性能遠(yuǎn)高于隨機(jī)讀寫
• 日志類數(shù)據(jù)可以使用順序讀寫方式進(jìn)行
• 將順序?qū)憯?shù)據(jù)和隨機(jī)讀寫數(shù)據(jù)分成不同的物理磁盤，有助于i/o壓力的疏解，前提是，你確信你的i/o壓力主要來(lái)自于可順序?qū)懖僮鳎ㄒ螂S機(jī)讀寫干擾導(dǎo)致不能順序?qū)?，但是確實(shí)可以用順序?qū)懛绞竭M(jìn)行的i/o操作）。

3.5.?運(yùn)維監(jiān)控體系

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