某些進程/服務消耗更多CPU資源（服務響應更多請求或存在某些應用瓶頸）；
發生比較嚴重的swap（可用物理內存不足）；
發生比較嚴重的中斷（因為SSD或網絡的原因發生中斷）；
磁盤I/O比較慢（會導致CPU一直等待磁盤I/O請求）；

絕對不要因表數據量小，sql語句隨便寫都行，隨便join都不會出現性能瓶頸，決不能有這
種思想。
盡量避免join表 join表笛卡爾積
如果要join表一定要把where條件寫全，安全起見最好加個limit。
一次請求讀寫的數據量太大，導致磁盤I/O讀寫值較大，例如一個SQL裏要讀取或更新幾萬>行數據甚至更多，這種最好是想辦法減少一次讀寫的數據量；

SQL查詢中沒有適當的索引可以用來完成條件過濾、排序（ORDER BY）、分組（GROUP BY）
、數據聚合（MIN/MAX/COUNT/AVG等），添加索引或者進行SQL改寫吧；
瞬間突發有大量請求，這種一般只要能扛過峰值就好，保險起見還是要適當提高服務器的>配置，萬一峰值抗不過去就可能發生雪崩效應；
因為某些定時任務引起的負載升高，比如做數據統計分析和備份，這種對CPU、內存、磁盤
I/O消耗都很大，最好放在獨立的slave服務器上執行；
服務器自身的節能策略發現負載較低時會讓CPU降頻，當發現負載升高時再自動升頻，但通
常不是那麽及時，結果導致CPU性能不足，抗不過突發的請求；
使用raid卡的時候，通常配備BBU（cache模塊的備用電池），早期一般采用鋰電池技術，>需要定期充放電（DELL服務器90天一次，IBM是30天），我們可以通過監控在下一次充放電
的時間前在業務低谷時提前對其進行放電，不過新一代服務器大多采用電容式電池，也就>不存在這個問題了。
文件系統采用ext4甚至ext3，而不是xfs，在高I/O壓力時，很可能導致%util已經跑到100%了，但iops卻無法再提升，換成xfs一般可獲得大幅提升；
內核的io scheduler策略采用cfq而非deadline或noop，可以在線直接調整，也可獲得大幅
提升。

mysql負載飆高原因分析