數據庫Mysql機能優化詳解。本站提示廣大學習愛好者：（數據庫Mysql機能優化詳解）文章只能為提供參考，不一定能成為您想要的結果。以下是數據庫Mysql機能優化詳解正文
在mysql數據庫中，mysql key_buffer_size是對MyISAM表機能影響最年夜的一個參數(留意該參數對其他類型的表設置有效)，上面就將對mysql Key_buffer_size參數的設置停止具體引見上面為一台以MyISAM為重要存儲引擎辦事器的設置裝備擺設：
mysql> show variables like 'key_buffer_size'; +-----------------+------------+ | Variable_name | Value | +-----------------+------------+ | key_buffer_size | | +-----------------+------------+
分派了512MB內存給mysql key_buffer_size，我們再看一下key_buffer_size的應用情形：
mysql> show global status like 'key_read%'; +------------------------+-------------+ | Variable_name | Value | +------------------------+-------------+ | Key_read_requests | | //從緩存讀取索引的要求次數。 | Key_reads | | //從磁盤讀取索引的要求次數。 +------------------------+-------------+
一共有27813678764個索引讀取要求，有6798830個要求在內存中沒有找到直接從硬盤讀取索引，盤算索引未射中緩存的幾率：
key_cache_miss_rate = Key_reads / Key_read_requests * 100%
好比下面的數據，key_cache_miss_rate為0.0244%，4000個索引讀取要求才有一個直接讀硬盤，曾經很BT了，key_cache_miss_rate在0.1%以下都很好(每1000個要求有一個直接讀硬盤)，所以實際來下去說，這個比值越小越好，但太小的話，不免形成內存糟蹋。
以上兩個值的比率雖然能一部門的解釋key_buffer_size能否公道，但僅僅以此就解釋該值設置的公道的話，就過於過火和單方面了。由於這裡疏忽了兩個成績：
1、比例其實不顯示數目的相對值年夜小
2、計數器並沒有斟酌時光身分
雖然說Key_read_requests年夜比小好，然則關於體系調優而言，更成心義的應當是單元時光內的Key_reads，即：
Key_reads / Uptime
詳細檢查辦法以下：
[root@web mysql]# mysqladmin ext -uroot -p -ri | grep Key_reads Enter password: | Key_reads | | | Key_reads | | | Key_reads | | | Key_reads | | | Key_reads | | | Key_reads | | | Key_reads | | | Key_reads | | | Key_reads | | | Key_reads | |
注：敕令裡的mysqladmin ext其實就是mysqladmin extended-status，你乃至可以簡寫成mysqladmin e。
個中第一行表現的是匯總數值，所以這裡不用斟酌，上面的每行數值都表現10秒內的數據變更，從這份數據可以看出每10秒體系年夜約會湧現500次Key_reads拜訪，折合到每1秒就是50次閣下，至於這個數值究竟公道與否，就由辦事器的磁盤才能而定了。(注：我這裡之所以數據變更較年夜，是由於有update等語句形成了表鎖而招致下個時光段內的查詢數猛增。)
為啥數據按10秒取樣，而不是直接按1秒取樣？因為時光段太小，數據變更比擬激烈，不輕易直不雅估量年夜小，所以平日數據依照10秒或許60秒之類的時光段來取樣是更好的。
除些以外，我們還可以參考下key_blocks_*參數：
mysql> show global status like 'key_blocks_u%'; +------------------------+-------------+ | Variable_name | Value | +------------------------+-------------+ | Key_blocks_unused | | | Key_blocks_used | | +------------------------+-------------+
Key_blocks_unused表現未應用的緩存簇(blocks)數，Key_blocks_used表現已經用到的最年夜的blocks數，好比這台辦事器，一切的緩存都用到了，要末增長key_buffer_size，要末就是過渡索引了，把緩存占滿了。比擬幻想的設置：
Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%
筆者注：
檢查簇（文件體系塊，block）的年夜小（字節數）
Centos中有以下幾種辦法：
#tune2fs /dev/sda1 | grep "block size"
#dumpe2fs /dev/sda1 | grep "block size"
實際上文件體系塊是扇區的倍數
mysqladmin是MySQL一個主要的客戶端，最多見的是應用它來封閉數據庫，除此，該敕令還可以懂得MySQL運轉狀況、過程信息、過程殺逝世等。本文引見一下若何應用mysqladmin extended-status(由於沒有"歧義"，所以可使用ext取代)懂得MySQL的運轉狀況。
1. 應用-r/-i參數
應用mysqladmin extended-status敕令可以取得一切MySQL機能目標，即show global status的輸入，不外，由於多半這些目標都是累計值，假如想懂得以後的狀況，則須要停止一次差值盤算，這就是mysqladmin extended-status的一個額定功效，異常適用。默許的，應用extended-status，看到也是累計值，然則，加上參數-r(--relative)，便可以看到各個目標的差值，合營參數-i(--sleep)便可以指定刷新的頻率，那末就有以下敕令：
mysqladmin -uroot -r -i -pxxx extended-status +------------------------------------------+----------------------+ | Variable_name | Value | +------------------------------------------+----------------------+ | Aborted_clients | | | Com_select | | | Com_insert | | ...... | Threads_created | | +------------------------------------------+----------------------+
2. 合營grep應用
合營grep應用，我們就有：
mysqladmin -uroot -r -i -pxxx extended-status \ grep "Questions\|Queries\|Innodb_rows\|Com_select \|Com_insert \|Com_update \|Com_delete " | Com_delete | | | Com_delete_multi | | | Com_insert | | | Com_select | | | Com_update | | | Innodb_rows_deleted | | | Innodb_rows_inserted | | | Innodb_rows_read | | | Innodb_rows_updated | | | Queries | | | Questions | 2721 |
固然，還可以合營awk等，筆者在這裡就紛歧一引見了，無情趣的同伙可以參考一下其它文檔。
