影響數據庫性能的因素

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

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

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

“系統性能問題需要從架構上解決，與應用開發關系不大?！?br /> 系統性能與各個層面都有關，架構很重要，但應用開發也是非常重要的一環。

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

在很多情況下，數據庫可能是互聯網應用系統的瓶頸。但是單純從數據庫角度去做優化，可能未必能達到理想的效果。

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