影響數(shù)據(jù)庫性能的因素

對于數(shù)據(jù)庫愛好者們，數(shù)據(jù)庫底層的各種細節(jié)，內幕，等待事件，隱藏參數(shù)等津津樂道，對于調整好一條SQL語句使之在查詢優(yōu)化器/查詢引擎下能高性能運轉具有巨大的滿足感成功感，仿佛自己掌握了天下最有價值的真理，駕馭了天下最有難度的技術。但對于設計和開發(fā)出這個數(shù)據(jù)庫系統(tǒng)的人來說，他們看到此情此景，只好躲在一邊偷偷的笑了。那么問題來了，使用別人數(shù)據(jù)庫的人被稱為大師（如：OCM），那么自己寫出一個數(shù)據(jù)庫來的人又該稱為什么呢？到底誰才是真正的高手呢？

數(shù)據(jù)庫系統(tǒng)優(yōu)化中的一些觀點：
“系統(tǒng)性能出現(xiàn)問題進行優(yōu)化，一定要深入了解數(shù)據(jù)庫內部參數(shù)、等待事件、Latch、緩沖池、trace文件、查詢/優(yōu)化引擎等底層細節(jié)?！?br /> 這種觀點往往出自數(shù)據(jù)庫“高手”，這部分人以了解數(shù)據(jù)庫底層實現(xiàn)細節(jié)而感到非常驕傲。但是從優(yōu)化角度講數(shù)據(jù)庫的等待事件、Latch等指標高等等都只是問題的表象，懂得底層細節(jié)和內幕固然是好。但是解決問題的關鍵往往是在應用層進行優(yōu)化。

“只要系統(tǒng)參數(shù)調整了，性能就能提高。系統(tǒng)優(yōu)化應該調整那些參數(shù)…”
這種觀點往往出自于一些偏運維和應用層的DBA，迷戀參數(shù)配置來調優(yōu)。
調整系統(tǒng)參數(shù)是非常重要的，但不一定能解決性能問題，否則就不會有去IOE了，問題可能性最大的還是應用設計和開發(fā)問題。
同理，很多運維人員和系統(tǒng)架構師比較迷戀“Linux系統(tǒng)調優(yōu)”。認為對“文件句柄數(shù)、磁盤子系統(tǒng)…”那些做了優(yōu)化，就能提升整個應用系統(tǒng)的性能。其實不然。有些場景下，針對業(yè)務特點和應用類型做操作系統(tǒng)調優(yōu)是能取到立竿見影的效果，但是大多數(shù)時候往往提升并不明顯。所以最關鍵的還是找出瓶頸所在，對癥下藥。*/

“系統(tǒng)性能問題需要從架構上解決，與應用開發(fā)關系不大。”
系統(tǒng)性能與各個層面都有關，架構很重要，但應用開發(fā)也是非常重要的一環(huán)。

影響數(shù)據(jù)庫性能的因素
1.業(yè)務需求和技術選型
2.應用系統(tǒng)的開發(fā)及架構
3.數(shù)據(jù)庫自身
3.1表結構的設計
3.2查詢語句
3.3索引設計
3.4Mysql服務（安裝、配置等）
3.5操作系統(tǒng)調優(yōu)
3.6硬件升級（SSD、更強的CPU、更大的內存）
4.數(shù)據(jù)架構（讀寫分離、分庫分表等）

在很多情況下，數(shù)據(jù)庫可能是互聯(lián)網(wǎng)應用系統(tǒng)的瓶頸。但是單純從數(shù)據(jù)庫角度去做優(yōu)化，可能未必能達到理想的效果。

說點題外話，最近看到很多公司使用中間件或者分布式數(shù)據(jù)訪問層來做數(shù)據(jù)庫分片，說明也許該公司業(yè)務發(fā)展很快。但另一個方面，也令人擔憂，他們的數(shù)據(jù)庫壓力真的已經(jīng)到了必須切分不可的程度了嗎？分庫分表真的像科普的那么簡單嗎？他們能搞定分庫分表帶來的成本和問題嗎？有沒有更合適的優(yōu)化方法呢？
當然是有的。其實“過度設計”和“提前優(yōu)化”就是系統(tǒng)萬惡之源。