數據庫性能優化的誤區

常見的數據庫系統優化中的一些觀點： 

「系統性能出現問題進行優化，必定要深刻了解數據庫內部參數、等待事件、Latch、緩衝池、trace文件、查詢/優化引擎等底層細節。」 
這種觀點每每出自數據庫「高手」，這部分人以瞭解數據庫底層實現細節而感到很是驕傲。可是從優化角度講數據庫的等待事件、Latch等指標高等等都只是問題的表象，懂得底層細節和內幕當然是好。可是解決問題的關鍵每每是在應用層進行優化。

「只要系統參數調整了，性能就能提升。系統優化應該調整那些參數…」 
這種觀點每每出自於一些偏運維和應用層的DBA，迷戀參數配置來調優。 
調整系統參數是很是重要的，但不必定能解決性能問題，不然就不會有去IOE了，問題可能性最大的仍是應用設計和開發問題。

同理，不少運維人員和系統架構師比較迷戀「Linux系統調優」。認爲的對「文件句柄數、CPU/內存/磁盤子系統…」各類參數作了優化，覺得這就能提高整個應用系統的性能。其實否則。有些場景下，針對業務特色和應用類型作操做系統調優是能取到立竿見影的效果，可是大多數時候每每提高並不明顯。因此最關鍵的仍是找出瓶頸所在，對症下藥。

「系統性能問題須要從架構上解決，與應用開發關係不大。」 
系統性能與各個層面都有關，總體架構很重要，但應用開發也是很是重要的一環。

「大家必需要作讀寫分離，必需要弄分庫分表。」

這種一般是「吹水」的人常在外面忽悠的，這些技術手段都被說爛了。

反問一句，瞭解數據量嗎？知道實際壓力和瓶頸嗎？瞭解讀寫好比何嗎？怎麼拆？拆了以後怎麼玩？ 

上述那些觀點，都是比較片面的，仍是須要結合實際狀況辯證分析。

 

常見影響數據庫性能的因素

1.業務需求和技術選型 

2.應用系統的開發及架構 

3.數據庫自身 

3.1表結構的設計 

3.2查詢語句 

3.3索引設計 

3.4Mysql服務（安裝、配置等） 

3.5操做系統調優 

3.6硬件升級（SSD、更強的CPU、更大的內存） 

4.數據架構（讀寫分離、分庫分表等）

 

性能調優的基本方法論

 

 

理想的數據庫優化順序

 

 

在不少狀況下，數據庫多是互聯網應用系統的最大瓶頸。可是單純從數據庫角度去作優化，可能未必能達到理想的效果。