mysql管理

1 連接 Connections

經常會遇見”mysql: error 1040: too many connections”的情況，一種是訪問量確實很高，mysql服務器抗不住，這個時候就要考慮增加從服務器分散讀壓力，另外一種情況是mysql配置文件中max_connections值過小：?


mysql> show variables like ‘max_connections‘;


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


| variable_name　 | value ? |


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


| max_connections | 256　 |


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


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


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


mysql服務器過去的最大連接數(shù)是245，沒有達到服務器連接數(shù)上限256，應該沒有出現(xiàn)1040錯誤，比較理想的設置是


?max_used_connections / max_connections * 100% ≈ 85%?


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


?


2 ?線程 Thread


mysql> show global status like ‘thread%‘;


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


| variable_name　　 | ? value |


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


| threads_cached　 | ? ?46　 |


| threads_connected | 2　　 |


| threads_created　| 570　 ?|


| threads_running ?| 1　 ?　 |


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


如果我們在mysql服務器配置文件中設置了thread_cache_size，當客戶端斷開之后，服務器處理此客戶的線程將會緩存起來以響應下一個客戶而不是銷毀（前提是緩存數(shù)未達上限）。


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


查詢服務器 thread_cache_size 配置：?


mysql> show variables like ‘thread_cache_size‘;


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


| variable_name　　 | value ? |


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


| thread_cache_size | 64　　 |


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


示例中的服務器還是挺健康的。


?


3 ?緩存 cache


3.1 文件打開數(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 |


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


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


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


3.2.1 打開數(shù) open_tables


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


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


| variable_name | value ? |


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


| open_tables　 | 919　 |


| opened_tables | 1951 |


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


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


opened_tables: 打開過的表數(shù)量


如果 opened_tables 數(shù)量過大，說明配置中 table_cache(5.1.3之后這個值叫做table_open_cache)值可能太小，我們查詢一下服務器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 臨時表 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)建臨時表，created_tmp_tables 增加，如果是在磁盤上創(chuàng)建臨時表，created_tmp_disk_tables也增加,created_tmp_files表示mysql服務創(chuàng)建的臨時文件文件數(shù)，比較理想的配置是：?


created_tmp_disk_tables / created_tmp_tables * 100% <= 25%?


比如上面的服務器 created_tmp_disk_tables / created_tmp_tables * 100% ＝ 1.20%，應該相當好了。我們再看一下mysql服務器對臨時表的配置：?


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 以下的臨時表才能全部放內存，超過的就會用到硬盤臨時表。?


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引擎，因為innodb是行鎖而myisam是表鎖，對于高并發(fā)寫入的應用innodb效果會好些。?


示例中的服務器 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 |


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


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


mysql> show global status like ‘com_select‘;


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


| variable_name | value　　　　　 |


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


| com_select　　　　 | 222693559 |


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


計算表掃描率：?


表掃描率 ＝ handler_read_rnd_next / com_select?


如果表掃描率超過 4000，說明進行了太多表掃描，很有可能索引沒有建好，增加 read_buffer_size 值會有一些好處，但最好不要超過8mb。?


3.3 key_buffer_size


key_buffer_size是對myisam表性能影響最大的一個參數(shù)，下面一臺以myisam為主要存儲引擎服務器的配置：?


mysql> show variables like ‘key_buffer_size‘;?


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


| variable_name　 | value　　　 |


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


| key_buffer_size | 536870912 |


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


分配了 512mb 內存給 key_buffer_size ，我們再看一下 key_buffer_size 的使用情況：?


mysql> show global status like ‘key_read%‘;


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


| variable_name　　　　　| value　 　　 |


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


| key_read_requests　　 | 27813678764 |


| key_reads　　　　　　 | 6798830　　　 |


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


?一共有 27813678764個 索引讀取請求，有 6798830個 請求在內存中沒有找到直接從硬盤讀取索引，計算索引未命中緩存的概率：?


key_cache_miss_rate ＝ key_reads / key_read_requests * 100%?


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


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


mysql服務器還提供了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 表示曾經用到的最大的blocks數(shù)


比如這臺服務器，所有的緩存都用到了，要么增加 key_buffer_size，要么就是過渡索引了，把緩存占滿了。比較理想的設置：?


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 首先會嘗試在內存中做排序，使用的內存大小由系統(tǒng)變量 sort_buffer_size 決定，如果它的大小不夠把所有的記錄都讀到內存中，mysql 就會把每次在內存中排序的結果存到臨時文件中，等 mysql 找到所有記錄之后，再把臨時文件中的記錄做一次排序。這再次排序就會增加 sort_merge_passes。實際上，mysql 會用另一個臨時文件來存再次排序的結果，所以通常會看到 sort_merge_passes 增加的數(shù)值是建臨時文件數(shù)的兩倍。因為用到了臨時文件，所以速度可能會比較慢，增加 sort_buffer_size 會減少 sort_merge_passes 和 創(chuàng)建臨時文件的次數(shù)。但盲目的增加 sort_buffer_size 并不一定能提高速度，見 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)的值對排序的操作也有一點的好處，參見：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：緩存中相鄰內存塊的個數(shù)。數(shù)目大說明可能有碎片。flush query cache會對緩存中的碎片進行整理，從而得到一個空閑塊。?


qcache_free_memory：緩存中的空閑內存。?


qcache_hits：每次查詢在緩存中命中時就增大?


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


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


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


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


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


?


我們再查詢一下服務器關于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：超過此大小的查詢將不緩存?


query_cache_min_res_unit：緩存塊的最小大小?


query_cache_size：查詢緩存大小?


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


query_cache_wlock_invalidate：當有其他客戶端正在對myisam表進行寫操作時，如果查詢在query cache中，是否返回cache結果還是等寫操作完成再讀表獲取結果。


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


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


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


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


查詢緩存利用率在25%以下的話說明query_cache_size設置的過大，可適當減??；查詢緩存利用率在80％以上而且qcache_lowmem_prunes > 50的話說明query_cache_size可能有點小，要不就是碎片太多。


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


示例服務器 查詢緩存碎片率 ＝ 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 ?|


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


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


打開慢查詢日志可能會對系統(tǒng)性能有一點點影響，如果你的mysql是主－從結構，可以考慮打開其中一臺從服務器的慢查詢日志，這樣既可以監(jiān)控慢查詢，對系統(tǒng)性能影響又小。