1 連接 Connections

經(jīng)常會(huì)遇見(jiàn)”mysql: error 1040: too many connections”的情況，一種是訪問(wèn)量確實(shí)很高，mysql服務(wù)器抗不住，這個(gè)時(shí)候就要考慮增加從服務(wù)器分散讀壓力，另外一種情況是mysql配置文件中max_connections值過(guò)?。?


mysql> show variables like ‘max_connections‘;


+-----------------+-------+


| variable_name　 | value ? |


+-----------------+-------+


| max_connections | 256　 |


+-----------------+-------+?


這臺(tái)mysql服務(wù)器最大連接數(shù)是256，然后查詢一下服務(wù)器響應(yīng)的最大連接數(shù)：


?mysql> show global status like ‘max_used_connections‘;?


mysql服務(wù)器過(guò)去的最大連接數(shù)是245，沒(méi)有達(dá)到服務(wù)器連接數(shù)上限256，應(yīng)該沒(méi)有出現(xiàn)1040錯(cuò)誤，比較理想的設(shè)置是


?max_used_connections / max_connections * 100% ≈ 85%?


最大連接數(shù)占上限連接數(shù)的85％左右，如果發(fā)現(xiàn)比例在10%以下，mysql服務(wù)器連接數(shù)上限設(shè)置的過(guò)高了。


?


2 ?線程 Thread


mysql> show global status like ‘thread%‘;


+-------------------+-------+


| variable_name　　 | ? value |


+-------------------+-------+


| threads_cached　 | ? ?46　 |


| threads_connected | 2　　 |


| threads_created　| 570　 ?|


| threads_running ?| 1　 ?　 |


+-------------------+-------+?


如果我們?cè)趍ysql服務(wù)器配置文件中設(shè)置了thread_cache_size，當(dāng)客戶端斷開(kāi)之后，服務(wù)器處理此客戶的線程將會(huì)緩存起來(lái)以響應(yīng)下一個(gè)客戶而不是銷毀（前提是緩存數(shù)未達(dá)上限）。


threads_created表示創(chuàng)建過(guò)的線程數(shù)，如果發(fā)現(xiàn)threads_created值過(guò)大的話，表明mysql服務(wù)器一直在創(chuàng)建線程，這也是比較耗資源，可以適當(dāng)增加配置文件中thread_cache_size值，


查詢服務(wù)器 thread_cache_size 配置：?


mysql> show variables like ‘thread_cache_size‘;


+-------------------+-------+


| variable_name　　 | value ? |


+-------------------+-------+


| thread_cache_size | 64　　 |


+-------------------+-------+?


示例中的服務(wù)器還是挺健康的。


?


3 ?緩存 cache


3.1 文件打開(kāi)數(shù)


mysql> show global status like ‘open_files‘;


+---------------+-------+


| variable_name | value |


+---------------+-------+


| open_files　　 | 1410　 |


+---------------+-------+


?mysql> show variables like ‘open_files_limit‘;


+------------------+-------+


| variable_name　　 | value |


+------------------+-------+


| open_files_limit ? ?| 4590 |


+------------------+-------+?


比較合適的設(shè)置：open_files / open_files_limit * 100% <= 75％


3.2 數(shù)據(jù)表


3.2.1 打開(kāi)數(shù) open_tables


mysql> show global status like ‘open%tables%‘;


+---------------+-------+


| variable_name | value ? |


+---------------+-------+


| open_tables　 | 919　 |


| opened_tables | 1951 |


+---------------+-------+?


open_tables: 打開(kāi)表的數(shù)量


opened_tables: 打開(kāi)過(guò)的表數(shù)量


如果 opened_tables 數(shù)量過(guò)大，說(shuō)明配置中 table_cache(5.1.3之后這個(gè)值叫做table_open_cache)值可能太小，我們查詢一下服務(wù)器table_cache值：?


mysql> show variables like ‘table_cache‘;


+---------------+-------+


| variable_name | value |


+---------------+-------+


| table_cache　　　 | 2048　 |


+---------------+-------+?


比較合適的值為：?


open_tables / opened_tables * 100% >= 85%?


open_tables / table_cache * 100% <= 95%


?3.2.2 臨時(shí)表 tmp_table


mysql> show global status like ‘created_tmp%‘;


+-------------------------+---------+


| variable_name　　　　　 | value　　 |


+-------------------------+---------+


| created_tmp_disk_tables | 21197　 |


| created_tmp_files　　　　| 58　　　 |


| created_tmp_tables　　 ?| 1771587 |


+-------------------------+---------+?


每次創(chuàng)建臨時(shí)表，created_tmp_tables 增加，如果是在磁盤上創(chuàng)建臨時(shí)表，created_tmp_disk_tables也增加,created_tmp_files表示mysql服務(wù)創(chuàng)建的臨時(shí)文件文件數(shù)，比較理想的配置是：?


created_tmp_disk_tables / created_tmp_tables * 100% <= 25%?


比如上面的服務(wù)器 created_tmp_disk_tables / created_tmp_tables * 100% ＝ 1.20%，應(yīng)該相當(dāng)好了。我們?cè)倏匆幌耺ysql服務(wù)器對(duì)臨時(shí)表的配置：?


mysql> show variables where variable_name in (‘tmp_table_size‘, ‘max_heap_table_size‘);


+---------------------+-----------+


| variable_name　　　 | value　　　　　 |


+---------------------+-----------+


| max_heap_table_size | 268435456 |


| tmp_table_size　　　 | 536870912 |


+---------------------+-----------+?


只有 256mb 以下的臨時(shí)表才能全部放內(nèi)存，超過(guò)的就會(huì)用到硬盤臨時(shí)表。?


3.2.3 表鎖情況


mysql> show global status like ‘table_locks%‘;


+-----------------------+-----------+


| variable_name　　　　 | value　　　 |


+-----------------------+-----------+


| table_locks_immediate | 490206328 |


| table_locks_waited　　| 2084912　 |


+-----------------------+-----------+


?table_locks_immediate 表示立即釋放表鎖數(shù)，?


table_locks_waited 表示需要等待的表鎖數(shù)，?


如果 table_locks_immediate / table_locks_waited > 5000，最好采用innodb引擎，因?yàn)閕nnodb是行鎖而myisam是表鎖，對(duì)于高并發(fā)寫入的應(yīng)用innodb效果會(huì)好些。?


示例中的服務(wù)器 table_locks_immediate / table_locks_waited ＝ 235，myisam就足夠了。


3.2.4 表掃描情況


mysql> show global status like ‘handler_read%‘;


+-----------------------+-------------+


| variable_name　　　　 | value　　　　 |


+-----------------------+-------------+


| handler_read_first　　| 5803750　　 ? |


| handler_read_key　　 | 6049319850 ?|


| handler_read_next　 ?| 94440908210 |


| handler_read_prev　 ?| 34822001724 |


| handler_read_rnd　　 | 405482605　 |


| handler_read_rnd_next | 18912877839 |


+-----------------------+-------------+


?各字段解釋參見(jiàn) http://hi.baidu.com/thinkinginlamp/blog/item/31690cd7c4bc5cdaa144df9c.html ，調(diào)出服務(wù)器完成的查詢請(qǐng)求次數(shù)：?


mysql> show global status like ‘com_select‘;


+---------------+-----------+


| variable_name | value　　　　　 |


+---------------+-----------+


| com_select　　　　 | 222693559 |


+---------------+-----------+?


計(jì)算表掃描率：?


表掃描率 ＝ handler_read_rnd_next / com_select?


如果表掃描率超過(guò) 4000，說(shuō)明進(jìn)行了太多表掃描，很有可能索引沒(méi)有建好，增加 read_buffer_size 值會(huì)有一些好處，但最好不要超過(guò)8mb。?


3.3 key_buffer_size


key_buffer_size是對(duì)myisam表性能影響最大的一個(gè)參數(shù)，下面一臺(tái)以myisam為主要存儲(chǔ)引擎服務(wù)器的配置：?


mysql> show variables like ‘key_buffer_size‘;?


+-----------------+------------+


| variable_name　 | value　　　 |


+-----------------+------------+


| key_buffer_size | 536870912 |


+-----------------+------------+?


分配了 512mb 內(nèi)存給 key_buffer_size ，我們?cè)倏匆幌?key_buffer_size 的使用情況：?


mysql> show global status like ‘key_read%‘;


+------------------------+-------------+


| variable_name　　　　　| value　 　　 |


+------------------------+-------------+


| key_read_requests　　 | 27813678764 |


| key_reads　　　　　　 | 6798830　　　 |


+------------------------+-------------+


?一共有 27813678764個(gè) 索引讀取請(qǐng)求，有 6798830個(gè) 請(qǐng)求在內(nèi)存中沒(méi)有找到直接從硬盤讀取索引，計(jì)算索引未命中緩存的概率：?


key_cache_miss_rate ＝ key_reads / key_read_requests * 100%?


比如上面的數(shù)據(jù)，key_cache_miss_rate為0.0244%，4000個(gè)索引讀取請(qǐng)求才有一個(gè)直接讀硬盤，已經(jīng)很bt了，key_cache_miss_rate在0.1%以下都很好（每1000個(gè)請(qǐng)求有一個(gè)直接讀硬盤），如果key_cache_miss_rate在0.01%以下的話，key_buffer_size分配的過(guò)多，可以適當(dāng)減少。?


【注意】key_read_buffer 默認(rèn)值為 8M 。在專有的數(shù)據(jù)庫(kù)服務(wù)器上，該值可設(shè)置為 RAM * 1/4


mysql服務(wù)器還提供了key_blocks_*參數(shù)：?


mysql> show global status like ‘key_blocks_u%‘;


+------------------------+-------------+


| variable_name　　　　 | value　　　　 |


+------------------------+-------------+


| key_blocks_unused　　| 0　　　　　　 |


| key_blocks_used　　　 | 413543 ?　　 |


+------------------------+-------------+?


key_blocks_unused 表示未使用的緩存簇(blocks)數(shù)


key_blocks_used 表示曾經(jīng)用到的最大的blocks數(shù)


比如這臺(tái)服務(wù)器，所有的緩存都用到了，要么增加 key_buffer_size，要么就是過(guò)渡索引了，把緩存占滿了。比較理想的設(shè)置：?


key_blocks_used / (key_blocks_unused + key_blocks_used) * 100% ≈ 80%


3.4 排序使用情況 sort_buffer


mysql> show global status like ‘sort%‘;


+-------------------+------------+


| variable_name　　 | value　　　 |


+-------------------+------------+


| sort_merge_passes | 29　　　 |


| sort_range　　　　| 37432840　 |


| sort_rows　　　　 | 9178691532 |


| sort_scan　　　　 | 1860569　　 |


+-------------------+------------+?


sort_merge_passes 包括兩步。mysql 首先會(huì)嘗試在內(nèi)存中做排序，使用的內(nèi)存大小由系統(tǒng)變量 sort_buffer_size 決定，如果它的大小不夠把所有的記錄都讀到內(nèi)存中，mysql 就會(huì)把每次在內(nèi)存中排序的結(jié)果存到臨時(shí)文件中，等 mysql 找到所有記錄之后，再把臨時(shí)文件中的記錄做一次排序。這再次排序就會(huì)增加 sort_merge_passes。實(shí)際上，mysql 會(huì)用另一個(gè)臨時(shí)文件來(lái)存再次排序的結(jié)果，所以通常會(huì)看到 sort_merge_passes 增加的數(shù)值是建臨時(shí)文件數(shù)的兩倍。因?yàn)橛玫搅伺R時(shí)文件，所以速度可能會(huì)比較慢，增加 sort_buffer_size 會(huì)減少 sort_merge_passes 和 創(chuàng)建臨時(shí)文件的次數(shù)。但盲目的增加 sort_buffer_size 并不一定能提高速度，見(jiàn) how fast can you sort data with mysql?（引自http://qroom.blogspot.com/2007/09/mysql-select-sort.html ，貌似被墻）?


另外，增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值對(duì)排序的操作也有一點(diǎn)的好處，參見(jiàn)：http://www.mysqlperformanceblog.com/2007/07/24/what-exactly-is-read_rnd_buffer_size/


3.5 查詢緩存


mysql> show global status like ‘qcache%‘;


+-------------------------+-----------+


| variable_name　　　　　| value　　　 |


+-------------------------+-----------+


| qcache_free_blocks　 ? | 22756　　 |


| qcache_free_memory　| 76764704　 |


| qcache_hits　　　　　　| 213028692 |


| qcache_inserts　　　　 | 208894227 |


| qcache_lowmem_prunes | 4010916 ?|


| qcache_not_cached　　| 13385031 ?|


| qcache_queries_in_cache | 43560　 |


| qcache_total_blocks　 | 111212 ?　 |


+-------------------------+-----------+


?mysql 查詢緩存變量解釋：?


qcache_free_blocks：緩存中相鄰內(nèi)存塊的個(gè)數(shù)。數(shù)目大說(shuō)明可能有碎片。flush query cache會(huì)對(duì)緩存中的碎片進(jìn)行整理，從而得到一個(gè)空閑塊。?


qcache_free_memory：緩存中的空閑內(nèi)存。?


qcache_hits：每次查詢?cè)诰彺嬷忻袝r(shí)就增大?


qcache_inserts：每次插入一個(gè)查詢時(shí)就增大。命中次數(shù)除以插入次數(shù)就是命中比率。?


qcache_lowmem_prunes：緩存出現(xiàn)內(nèi)存不足并且必須要進(jìn)行清理以便為更多查詢提供空間的次數(shù)。這個(gè)數(shù)字最好長(zhǎng)時(shí)間來(lái)看；如果這個(gè)數(shù)字在不斷增長(zhǎng)，就表示可能碎片非常嚴(yán)重，或者內(nèi)存很少。（上面的 free_blocks和free_memory可以告訴您屬于哪種情況）?


qcache_not_cached：不適合進(jìn)行緩存的查詢的數(shù)量，通常是由于這些查詢不是 select 語(yǔ)句或者用了now()之類的函數(shù)。?


qcache_queries_in_cache：當(dāng)前緩存的查詢（和響應(yīng)）的數(shù)量。?


qcache_total_blocks：緩存中塊的數(shù)量。?


?


我們?cè)俨樵円幌路?wù)器關(guān)于query_cache的配置：?


mysql> show variables like ‘query_cache%‘;


+------------------------------+-----------+


| variable_name　　　　　　　 | value　　　 |


+------------------------------+-----------+


| query_cache_limit　　　　　 | 2097152　 |


| query_cache_min_res_unit　| 4096　　　|


| query_cache_size　　　　　 ?| 203423744 |


| query_cache_type　　　　　| on　　　　 |


| query_cache_wlock_invalidate | off　　 ? |


+------------------------------+----------+?


各字段的解釋：?


query_cache_limit：超過(guò)此大小的查詢將不緩存?


query_cache_min_res_unit：緩存塊的最小大小?


query_cache_size：查詢緩存大小?


query_cache_type：緩存類型，決定緩存什么樣的查詢，示例中表示不緩存 select sql_no_cache 查詢


query_cache_wlock_invalidate：當(dāng)有其他客戶端正在對(duì)myisam表進(jìn)行寫操作時(shí)，如果查詢?cè)趒uery cache中，是否返回cache結(jié)果還是等寫操作完成再讀表獲取結(jié)果。


query_cache_min_res_unit的配置是一柄”雙刃劍”，默認(rèn)是4kb，設(shè)置值大對(duì)大數(shù)據(jù)查詢有好處，但如果你的查詢都是小數(shù)據(jù)查詢，就容易造成內(nèi)存碎片和浪費(fèi)。


查詢緩存碎片率 = qcache_free_blocks / qcache_total_blocks * 100%?


如果查詢緩存碎片率超過(guò)20%，可以用flush query cache整理緩存碎片，或者試試減小query_cache_min_res_unit，如果你的查詢都是小數(shù)據(jù)量的話。?


查詢緩存利用率 = (query_cache_size - qcache_free_memory) / query_cache_size * 100%?


查詢緩存利用率在25%以下的話說(shuō)明query_cache_size設(shè)置的過(guò)大，可適當(dāng)減??；查詢緩存利用率在80％以上而且qcache_lowmem_prunes > 50的話說(shuō)明query_cache_size可能有點(diǎn)小，要不就是碎片太多。


查詢緩存命中率 = (qcache_hits - qcache_inserts) / qcache_hits * 100%?


示例服務(wù)器 查詢緩存碎片率 ＝ 20.46％，查詢緩存利用率 ＝ 62.26％，查詢緩存命中率 ＝ 1.94％，命中率很差，可能寫操作比較頻繁吧，而且可能有些碎片。


4 其他


4.1 read_buffer_size


4.2 慢查詢


mysql> show variables like ‘%slow%‘;


+------------------+-------+


| variable_name　 ? | value ?|


+------------------+-------+


| log_slow_queries | on　　 |


| slow_launch_time | 2　 　 |


+------------------+-------+


mysql> show global status like ‘%slow%‘;


+---------------------+-------+


| variable_name　　　 | value ? |


+---------------------+-------+


| slow_launch_threads | 0 ?　 ?|


| slow_queries　　　　| 4148 ?|


+---------------------+-------+?


配置中打開(kāi)了記錄慢查詢，執(zhí)行時(shí)間超過(guò)2秒的即為慢查詢，系統(tǒng)顯示有4148個(gè)慢查詢，你可以分析慢查詢?nèi)罩?，找出有?wèn)題的sql語(yǔ)句，慢查詢時(shí)間不宜設(shè)置過(guò)長(zhǎng)，否則意義不大，最好在5秒以內(nèi)，如果你需要微秒級(jí)別的慢查詢，可以考慮給mysql打補(bǔ)?。篽ttp://www.percona.com/docs/wiki/release:start，記得找對(duì)應(yīng)的版本。?


打開(kāi)慢查詢?nèi)罩究赡軙?huì)對(duì)系統(tǒng)性能有一點(diǎn)點(diǎn)影響，如果你的mysql是主－從結(jié)構(gòu)，可以考慮打開(kāi)其中一臺(tái)從服務(wù)器的慢查詢?nèi)罩?，這樣既可以監(jiān)控慢查詢，對(duì)系統(tǒng)性能影響又小。