MySQL效能調優"經驗"

markzy5201190發表於2012-09-08
MySql
找出瓶頸:
儲存容量
Network(IOPS/吞吐量)
DRAM
CPU
IO(IOPS/吞吐量)【oltp:iops
olap:吞吐量
>60% 瓶頸在IO
】
以前DB大多效能在IO層面,現在CPU也可能會成為瓶頸,因是
排序和重複讀取過多導致;

方法及誤區：
DISK:【
oltp:小容量 高轉速
olap：大容量低轉速
磁碟數量儘可能多
      】
Raid Card：
     【
Cache只供寫使用，Direct讀取
oltp Raid10 參考DB
olap Raid5
關注Raid卡重放點帶來的Cache失效
預讀只對連續讀有效，oltp關閉預讀
      】
CPU：
      【
提高CPU運算能力
縮短CPU訪問資料路徑(緩村?)
       】

優化目標:

減少IO次數，
IO最容易瓶頸地方,同時>90%的時間是IO操作所佔用,
減少IO次數是SQL優先考慮；

減低CPU計算：
除IO瓶頸之外,SQL優化中就是CPU運算量，order by,
group by,distinct 都是消耗CPU大戶

優化方法：

改變SQL執行計劃
讓他 少走彎路，儘量通過各種 "捷徑" 來找到我們需要資料，
以達到 "減少IO次數" 和 "減低CPU計算"的目標
解釋：
count(column) 和 count(*) 是一樣的
count(column)是結果集中有多少個不為空記錄的column欄位;
count(*) 是表示整個結果集有多少條記錄
select a,b from xx 比 select a,b,c from .. 可以讓資料庫訪問
更少的資料量
資料庫的儲存原理：
關係型DB是按照行(row)的方式"儲存"，而資料"存取"操作是以一個固定
大小的IO單元(block 或 page)為單位，一般4KB,8KB ...,每個IO單元儲存多行,每行是儲存了該行的所有欄位。
所以,我們提取一個欄位還是多個欄位,實際上DB在表中訪問資料量其實是一樣的；
例外，我們這個查詢在index中就可以完成，也就是說只取a,b兩個欄位，
不需要回表，而c這個欄位不在使用index中,需要回表取其資料，在此情況下，二者IO量有較大差異.

order by 一定需要排序操作
index資料實際是有序的，如果我們需要資料和某個index的順序一致，
而且我們的查詢又通過這個index來執行，那麼DB一般會省去排序操作，而直接將資料返回，因為DB知道資料已經滿足我們的排序需求啦；

基本原則:
儘量少join，
儘量少排序，排序操作會消耗較多CPU資源，所以減少排序可以快取命中率高等IO能力，對SQL響應時間也有較大影響;
儘量避免select *
多數不會影響IO量,但是我們存在order by 網路傳輸資料時
select子句中欄位多少會再很大程度上影響排序效率

儘量用union all(union)替代 or
union 和 union all差異主要是前者將2個或更多結果集合並後再進行唯一性過濾，會涉及排序，增加大量CPU運算，資源消耗及延遲，所以，
多用union all 而不是union

儘量早過濾
可能多的減少必要IO操作，大大節省IO操作所消耗時間。

摘自網路

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26855487/viewspace-742933/，如需轉載，請註明出處，否則將追究法律責任。

相關文章