影響資料庫性能的因素

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

資料庫系統優化中的一些觀點：

“系統性能出現問題進行優化，一定要深入了解資料庫内部參數、等待事件、Latch、緩沖池、trace檔案、查詢/優化引擎等底層細節。”

這種觀點往往出自資料庫“高手”，這部分人以了解資料庫底層實作細節而感到非常驕傲。但是從優化角度講資料庫的等待事件、Latch等名額高等等都隻是問題的表象，懂得底層細節和内幕固然是好。但是解決問題的關鍵往往是在應用層進行優化。

“隻要系統參數調整了，性能就能提高。系統優化應該調整那些參數…”

這種觀點往往出自于一些偏運維和應用層的DBA，迷戀參數配置來調優。

調整系統參數是非常重要的，但不一定能解決性能問題，否則就不會有去IOE了，問題可能性最大的還是應用設計和開發問題。

同理，很多運維人員和系統架構師比較迷戀“Linux系統調優”。認為對“檔案句柄數、磁盤子系統…”那些做了優化，就能提升整個應用系統的性能。其實不然。有些場景下，針對業務特點和應用類型做作業系統調優是能取到立竿見影的效果，但是大多數時候往往提升并不明顯。是以最關鍵的還是找出瓶頸所在，對症下藥。*/

“系統性能問題需要從架構上解決，與應用開發關系不大。”

系統性能與各個層面都有關，架構很重要，但應用開發也是非常重要的一環。

影響資料庫性能的因素

1.業務需求和技術選型

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

3.資料庫自身

3.1表結構的設計

3.2查詢語句

3.3索引設計

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

3.5作業系統調優

3.6硬體更新（SSD、更強的CPU、更大的記憶體）

4.資料架構（讀寫分離、分庫分表等）

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

說點題外話，最近看到很多公司使用中間件或者分布式資料通路層來做資料庫分片，說明也許該公司業務發展很快。但另一個方面，也令人擔憂，他們的資料庫壓力真的已經到了必須切分不可的程度了嗎？分庫分表真的像科普的那麼簡單嗎？他們能搞定分庫分表帶來的成本和問題嗎？有沒有更合适的優化方法呢？

當然是有的。其實“過度設計”和“提前優化”就是系統萬惡之源。