(一)減少資料庫訪問
對於可以靜態化的頁面,儘可能靜態化
對一個動態網頁面中可以靜態局部,採用靜態化
部分資料可以產生XML,或者文字檔形式儲存
使用資料緩衝技術,例如: MemCached
(二)最佳化的檢測方法
1.使用者體驗檢測
2.Mysql狀態檢測
在Mysql命令列裡面使用show status命令,得到當前mysql狀態。
主要關注下列屬性:
key_read_requests (索引讀的請求數)(key_buffer_size設定影響)
key_reads(索引讀響應數)
Key_blocks_used
Qcache_*
Open_tables(通過table_cache的設定影響)
Opened_tables
table_locks
3. 第三方工具檢測
mysqlreporthttp://hackmysql.com/mysqlreport
mytophttp://jeremy.zawodny.com/mysql/mytop/
系統及Mysql的Log
系統命令: top, sar
Mysql的Log: slow_query.log
(三)硬體方面的最佳化
硬體方面,最容易成為Mysql瓶頸的部分是磁碟,其次是CPU和記憶體
磁碟方面
使用更快的磁碟,會對Mysql有很好的協助
使用更多的硬碟,通過Raid,可以提高單塊磁碟速度的問題
對於Raid方式,建議採用Raid 0+1 或者 Raid 1+0
CPU
毫無疑問,更高主頻的CPU和更多的CPU數量可以給Mysql更
高的效能
記憶體
更高的記憶體,往往可以讓Mysql中的更多的資料緩衝在記憶體中,
但是,一個重要的因素是,需要有正確的Mysql的配置
網卡
使用千兆網卡及千兆網路
(四)作業系統方面的最佳化
1.不使用交換區。如果記憶體不足,增加更多的記憶體或配置你的系統使用較少記憶體
2. 不要使用NFS磁碟
3.增加系統和MySQL伺服器的開啟檔案數量
使用ulimit –n 65535
4.增加系統的進程和線程數量。 5.關閉不必要的應用,最佳化硬碟參數,使用hdparm測試
(五)應用級的最佳化
1.使用多伺服器負載平衡(多台讀和寫,用複製技術進行資料同步)
2.表的分區 (自訂分區,mysql5.1開始支援內建資料分割函數)
3.使用資料緩衝技術memcached
(六)Mysql配置的最佳化
1.key_buffer(=512):索引緩衝使用的記憶體數量
這對MyISAM表來說非常重要,設定在可用記憶體的25%-30%較好,通過檢查狀態值 Key_read_requests和 Key_reads,
可以知道key_buffer設定是否合理。比例key_reads / key_read_requests應該儘可能的低,至少是1:100,1:1000更好 ,否則說明 key_buffer 設定有點偏小
2.innodb_buffer_pool_size(= 512):索引緩衝使用的記憶體數量
3.table_cache (=1024):資料表緩衝區的尺寸
每當 MySQL 訪問一個表時,如果在表緩衝區中還有空間,該表就被開啟並放入其中,這樣可以更快地訪問表內容。
通過檢查運行峰值時間的 Open_tables 和 Opened_tables 狀態值,可以決定是否需要調整 table_cache 的值。
如果你發現 open_tables 的值等於 table_cache,並且發現 opened_tables 狀態值在不斷增長,那麼你就需要增加 table_cache 參數值了,
也不能盲目地把 table_cache 參數設定成很大的值,如果設定得太高,可能會造成檔案描述符不足,從而造成效能不穩定或者串連失敗。
4.sort_buffer_size (=256):指定排序用緩衝區的長度
該參數對應的分配記憶體是每串連獨佔!如果有100個串連,那麼實際分配的總共排序緩衝區大小為100 × 6 = 600MB。
所以,對於記憶體在4GB左右的伺服器推薦設定為6-8M
5.join_buffer_size :關聯查詢用緩衝區的長度
4G記憶體以上,建議大於32M,該參數對應的分配記憶體也是每串連獨享!
6.max_connections (=1024):可以複用的線程數量
允許同時串連MySQL伺服器的客戶數量 ,可以觀察和估計系統在峰值最大的並發串連數來設定
7.thread_cache(=*):可以複用的線程數量
一般設定為CPU數×2
8.innodb_buffer_pool_size(= 512):innodb表緩衝池大小
這對Innodb表來說非常重要。Innodb相比MyISAM表對緩衝更為敏感。MyISAM可以在預設的 key_buffer_size 設定下啟動並執行可以,
然而Innodb在預設的innodb_buffer_pool_size 設定下卻跟蝸牛似的。
由於Innodb把資料和索引都緩衝起來,無需留給作業系統太多的記憶體,因此如果只需要用Innodb的話則可以設定它高達 70-80% 的可用記憶體。
一些應用於 key_buffer 的規則有 -- 如果你的資料量不大,並且不會暴增,那麼無需把innodb_buffer_pool_size 設定的太大了.
9.innodb_flush_logs_at_trx_commit(=1) :事務提交後的日誌重新整理模式
是否為Innodb比MyISAM慢1000倍而頭大?看來也許你忘了修改這個參數了。預設值是 1,這意味著每次提交的更新事務(或者每個事務之外的語句)都會重新整理到磁碟中,
而這相當耗費資源,尤其是沒有電池備用緩衝時。很多應用程式,尤其是從 MyISAM轉變過來的那些,把它的值設定為 2 就可以了,也就是不把日誌重新整理到磁碟上,
而只重新整理到作業系統的緩衝上。日誌仍然會每秒重新整理到磁碟中去,因此通常不會丟失每秒1-2次更新的消耗。如果設定為0就快很多了,不過也相對不安全了,
MySQL伺服器崩潰時就會丟失一些事務。設定為2指揮丟失重新整理到作業系統緩衝的那部分事務.