最近這段時間剛做了一項效能優化的工作，根據一周的statspack報告，寫了乙個優化方案。
一、系統現有的主要效能問題
從最近一周比較典型的statspack報告來看，系統中主要的等待事件如下：
top 5 timed events
event waits time (s) % total ela time
cpu time 5,819 46.04
wait for unread message on broadcast channel 3,356 3,374 26.70
db file sequential read 1,100,056 2,454 19.41
buffer busy waits 51,054 274 2.16
db file scattered read 154,540 220 1.74
資料庫中有46％的時間花費在cpu相關的操作上。cpu time可以分為3個部分，即cpu time= parse time cpu + recursive cpu usage +other cpu usage，其中，parse time cpu表示解析sql語句所花費的cpu時間，recursive cpu usage表示一些遞迴sql操作花費的cpu時間，other cpu usage代表邏輯讀取花費的cpu時間。
變換一下上述公式，other cpu usage＝cpu time － parse time cpu － recursive cpu usage，將我們的statspack報告的相關資料帶入該公式other cpu usage＝5819－584－109＝5126，由此可見，88％的cpu時間花費在了邏輯讀取資料的操作上，另外有10％的cpu時間花費在了解析sql語句上。我們可以從優化sql語句方面入手，降低邏輯讀取。另外，我們也可以在降低sql解析數方面做些工作。
等待事件wait for unread message on broadcast channel是乙個空閒事件，我們無須處理。
db file sequential read等待事件佔總時間的19％，表示物理讀取資料，減少該等待可以從兩個方面來考慮，首先是優化sql，降低不必要的物理讀取；另外也可以適當的增大資料緩衝區，使盡可能多的資料快取到記憶體中。
另外乙個等待事件buffer busy waits是由大量邏輯讀取所導致的記憶體等待，該事件也可以通過優化sql語句來消除。
二、解決方案
根據系統中存在的上述問題，提出如下的優化方案：
1） 優化一些邏輯讀和物理讀較多的sql，可以有效減少資料的讀取，也可以減少記憶體爭用；
2） 對一些執行頻繁的sql使用繫結變數，減少花費在解析sql語句上的cpu時間和記憶體栓鎖；
3） 適當增大資料緩衝區尺寸，減少物理讀。
oracle效能優化一 簡介
資料庫是資訊系統中核心的部分，資料庫的高效性 安全性 穩定性 延展性，是專案成功的關鍵之一。乙個好的資料庫系統，設計當然是關鍵，但是就像顯微鏡的粗調和微調，當軟體開發完成後，通過不斷的對系統的跟蹤監控，對資料庫系統進行優化也是必不可少的。可以認為優化是資料庫設計的一種順延，和設計是相輔相成的。資料庫...
mysql效能優化簡書 mysql 效能優化
1 伺服器層面 引數配置優化 減少客戶端使用連線數 可考慮使用快取 2 架構層面 讀寫分離 分庫 分表 分片 3 業務sql層面 檢視慢查詢日誌 sql優化 show variables like slow query 預設關閉 檢視日誌路徑 show variables like long que...
mysql效能優化簡書 MySQL效能優化
1 合理的建立及使用索引，索引不宜過多，過多的索引會占用更多的空間，而且每次增 刪 改操作都會重建索引。2 合理的冗餘字段 盡量建一些大表，考慮資料庫的三正規化和業務設計的取捨 3 select語句中盡量不要使用 count 從表中讀取越多的資料，查詢會變得更慢，因為它會增加了磁碟操作時間和資料網路...