論壇上的資料庫愛好者們，對於資料庫底層的各種細節，內幕，等待事件，隱藏引數等津津樂道，對於調整好一條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.資料架構（讀寫分離、分庫分表等）
在很多情況下，資料庫可能是網際網路應用系統的瓶頸。但是單純從資料庫角度去做優化，可能未必能達到理想的效果。
說點題外話，最近看到很多公司使用中介軟體或者分布式資料訪問層來做資料庫分片，說明也許該公司業務發展很快。但另乙個方面，也令人擔憂，他們的資料庫壓力真的已經到了必須切分不可的程度了嗎？分庫分表真的像科普的那麼簡單嗎？他們能搞定分庫分表帶來的成本和問題嗎？有沒有更合適的優化方法呢？
當然是有的。其實「過度設計」和「提前優化」就是系統萬惡之源。
影響資料庫的效能的因素
1 sql 查詢的速度 2 伺服器硬體 3 網絡卡流量 4 磁碟io 系統吞度量要素 乙個系統的吞度量 承壓能力 與request對cpu的消耗 外部介面 io等等緊密關聯。單個reqeust 對cpu消耗越高，外部系統介面 io影響速度越慢，系統吞吐能力越低，反之越高。系統吞吐量幾個重要引數 qp...
1 影響mysql資料庫效能因素
影響資料庫的效能因素 1.超高的qps和tps 1 qps 每秒查詢率 query per second 每秒查詢率qps是對乙個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。即每秒的響應請求數，也即是最大吞吐能力。2 tps 每秒事務處理量 transaction per second 每...
影響資料庫的因素
1.sql查詢速度 2.伺服器硬體 3.網絡卡流量 4.磁碟io 超高的qps和tps的風險 效率低下的sql 大量的併發風險 資料庫連線數被沾滿 max connections預設100，引數改的大一些 超高的cpu使用率 cpu資源耗盡而宕機 磁碟io 磁碟io效能突然下降 通過使用更快磁碟裝置...