status優化mysql

1. 1.       慢查詢。

mysql> show global variables like '%slow%' ;

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

| Variable_name       | Value                               |

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

| log_slow_queries    | ON                                  |  是否開啓

| slow_launch_time    | 2                                   |

| slow_query_log      | ON                                  |

| slow_query_log_file | /usr/local/mysql/var/LNMP4-slow.log |        存放位置

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

4 rows in set (0.00 sec)

 

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

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

| Variable_name       | Value |

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

| Slow_launch_threads | 0     |

| Slow_queries        | 0    |         查看有多少條慢查詢

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

2 rows in set (0.00 sec)

打開慢查詢日誌可能會對系統性能有一點點影響，若是你的mysql是主－從結構，能夠考慮打開其中一臺從服務器的慢查詢日誌，這樣既能夠監控慢查詢，對系統性能影響又小。

 

1. 2.       鏈接數。

 mysql> show global variables like '%max_connect%' ;

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

| Variable_name      | Value |

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

| max_connect_errors | 30000 |

| max_connections    | 5000  |              最大鏈接數

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

2 rows in set (0.00 sec)

 

mysql> show global status like 'Max_%connect%';

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

| Variable_name        | Value |

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

| Max_used_connections | 10    |

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

1 row in set (0.00 sec)

比較理想的設置是

max_used_connections / max_connections * 100% ≈ 85%

 

 

1. 3.       Key_buffer_size

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

mysql> show global variables like 'key_buffer_size';

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

| Variable_name   | Value     |

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

| key_buffer_size | 536870912 |                  512M

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

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

1 row in set (0.00 sec)

mysql> show global status like '%key_read%';

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

| Variable_name     | Value |

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

| Key_read_requests | 7696  |

| Key_reads         | 99    |

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

2 rows in set (0.00 sec)

計算索引未命中緩存的機率：

key_cache_miss_rate ＝ key_reads / key_read_requests * 100%

key_cache_miss_rate在0.1%如下都很好（每1000個請求有一個直接讀硬盤），若是key_cache_miss_rate在0.01%如下的話，key_buffer_size分配的過多，能夠適當減小。

 

 

mysql服務器還提供了key_blocks_*參數：

mysql> show global status like '%key_block%';

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

| Variable_name          | Value  |

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

| Key_blocks_not_flushed | 0      |

| Key_blocks_unused      | 428585 |

| Key_blocks_used        | 99     |

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

3 rows in set (0.00 sec)

key_blocks_unused表示未使用的緩存簇(blocks)數，key_blocks_used表示曾經用到的最大的blocks數，好比這臺服務器，全部的緩存都用到了，要麼增長key_buffer_size，要麼就是過渡索引了，把緩存佔滿了。比較理想的設置：

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

 

1. 4.       臨時表

 mysql> show global status like '%created_tmp%';

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

| Variable_name           | Value |

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

| Created_tmp_disk_tables | 2     |

| Created_tmp_files       | 0     |

| Created_tmp_tables      | 162   |

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

3 rows in set (0.00 sec)

 

每次建立臨時表，created_tmp_tables增長，若是是在磁盤上建立臨時表，created_tmp_disk_tables也增長,created_tmp_files表示mysql服務建立的臨時文件文件數，比較理想的配置是：

　　created_tmp_disk_tables / created_tmp_tables * 100% <= 25%好比上面的服務器created_tmp_disk_tables / created_tmp_tables * 100% ＝ 1.20%，應該至關好了。咱們再看一下mysql服務器對臨時表的配置：

mysql> show global variables where Variable_name = 'max_heap_table_size' or Variable_name = 'tmp_table_size';

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

| Variable_name       | Value     |

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

| max_heap_table_size | 268435456 |        256M

| tmp_table_size      | 134217728 |        128M

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

2 rows in set (0.00 sec)

只有256mb如下的臨時表才能所有放內存，超過的就會用到硬盤臨時表。

1. 5.       open table狀況

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

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

| Variable_name | Value |

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

| Open_tables   | 142   |

| Opened_tables | 227   |

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

2 rows in set (0.00 sec)

 open_tables表示打開表的數量，opened_tables表示打開過的表數量，若是opened_tables數量過大，說明配置中table_cache(5.1.3以後這個值叫作table_open_cache)值可能過小，咱們查詢一下服務器table_cache值：

mysql> show global variables like '%open%';

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

| Variable_name    | Value    |

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

| open_files_limit | 99999    |

| table_open_cache | 2048     |

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

3 rows in set (0.00 sec)

比較合適的值爲：

open_tables / opened_tables * 100% >= 85%

open_tables / table_cache * 100% <= 95%

1. 6.       線程使用狀況

若是咱們在mysql服務器配置文件中設置了thread_cache_size，當客戶端斷開以後，服務器處理此客戶的線程將會緩存起來以響應下一個客戶而不是銷燬（前提是緩存數未達上限）。

 

mysql> show global status like 'Thread%';

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

| Variable_name     | Value |

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

| Threads_cached    | 2     |

| Threads_connected | 5     |

| Threads_created   | 7     |

| Threads_running   | 2     |

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

4 rows in set (0.00 sec)

 

threads_created表示建立過的線程數，若是發現threads_created值過大的話，代表mysql服務器一直在建立線程，這也是比較耗資源，能夠適當增長配置文件中thread_cache_size值，查詢服務器thread_cache_size配置：

mysql> show global variables like '%thread_cache%';

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

| Variable_name     | Value |

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

| thread_cache_size | 64    |

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

1 row in set (0.00 sec)

1. 7.       查詢緩存(query cache)

   主要涉及兩個參數，query_cache_size，query_cache_type

     mysql> show global status like 'qcache%';              

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

| Variable_name           | Value |

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

| Qcache_free_blocks      | 0     |

| Qcache_free_memory      | 0     |

| Qcache_hits             | 0     |

| Qcache_inserts          | 0     |

| Qcache_lowmem_prunes    | 0     |

| Qcache_not_cached       | 0     |

| Qcache_queries_in_cache | 0     |

| Qcache_total_blocks     | 0     |

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

8 rows in set (0.00 sec)             因爲服務器還未上線因此查詢不多
 

mysql> show variables like 'query_cache%';

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

| Variable_name                | Value   |

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

| query_cache_limit            | 1048576 |

| query_cache_min_res_unit     | 4096    |

| query_cache_size             | 0       |

| query_cache_type             | ON      |

| query_cache_wlock_invalidate | OFF     |

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

5 rows in set (0.00 sec)

 

各字段的解釋：

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，設置值大對大數據查詢有好處，但若是你的查詢都是小數據查詢，就容易形成內存碎片和浪費。

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

若是查詢緩存碎片率超過20%，能夠用flush query cache整理緩存碎片，或者試試減少query_cache_min_res_unit，若是你的查詢都是小數據量的話。

查詢緩存利用率 = (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％，命中率不好，可能寫操做比較頻繁吧，並且可能有些碎片。

 

1. 8.       排序使用狀況

  mysql> show global status like 'sort%';

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

| Variable_name     | Value |

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

| Sort_merge_passes | 0     |

| Sort_range        | 0     |

| Sort_rows         | 0     |

| Sort_scan         | 0     |

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

4 rows in set (0.00 sec)

  

sort_merge_passes 包括兩步。mysql 首先會嘗試在內存中作排序，使用的內存大小由系統變量 sort_buffer_size 決定，若是它的大小不夠把全部的記錄都讀到內存中，mysql 就會把每次在內存中排序的結果存到臨時文件中，等 mysql 找到全部記錄以後，再把臨時文件中的記錄作一次排序。這再次排序就會增長 sort_merge_passes。實際上，mysql 會用另外一個臨時文件來存再次排序的結果，因此一般會看到 sort_merge_passes 增長的數值是建臨時文件數的兩倍。由於用到了臨時文件，因此速度可能會比較慢，增長 sort_buffer_size 會減小 sort_merge_passes 和 建立臨時文件的次數。但盲目的增長 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/

 

 

1. 9.       文件打開數

 mysql> show global status like 'open_files';

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

| Variable_name | Value |

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

| Open_files    | 23    |

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

1 row in set (0.01 sec)

  mysql> show global variables like '%open_file%';

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

| Variable_name    | Value |

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

| open_files_limit | 99999 |                    該參數修改LINUX內核

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

1 row in set (0.00 sec)

 

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

 

 

1. 10.   鎖表狀況

 mysql> show global status like 'table_lock%';

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

| Variable_name         | Value |

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

| Table_locks_immediate | 17    |

| Table_locks_waited    | 0     |

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

2 rows in set (0.00 sec)

table_locks_immediate表示當即釋放表鎖數，table_locks_waited表示須要等待的表鎖數，若是table_locks_immediate / table_locks_waited > 5000，最好採用innodb引擎，由於innodb是行鎖而myisam是表鎖，對於高併發寫入的應用innodb效果會好些。示例中的服務器table_locks_immediate / table_locks_waited ＝ 235，myisam就足夠了。

 

1. 11.   表掃描狀況

   mysql> show global status like '%handler_read%';

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

| Variable_name         | Value |

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

| Handler_read_first    | 3     |

| Handler_read_key      | 0     |

| Handler_read_next     | 0     |

| Handler_read_prev     | 0     |

| Handler_read_rnd      | 0     |

| Handler_read_rnd_next | 120   |

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

6 rows in set (0.00 sec)

 Handler_read_first 此選項代表SQL是在作一個全索引掃描，注意是所有，而不是部分，因此說若是存在WHERE語句，這個選項是不會變的。若是這個選項的數值很大，既是好事也是壞事。說它好是由於畢竟查詢是在索引裏完成的，而不是數據文件裏，說它壞是由於大數據量時，簡即是索引文件，作一次完整的掃描也是很費時的

Handler_read_key 此選項數值若是很高，那麼恭喜你，你的系統高效的使用了索引，一切運轉良好。

Handler_read_next 此選項代表在進行索引掃描時，按照索引從數據文件裏取數據的次數。

Handler_read_prev 此選項代表在進行索引掃描時，按照索引倒序從數據文件裏取數據的次數，通常就是ORDER BY ... DESC。

Handler_read_rnd 簡單的說，就是查詢直接操做了數據文件，不少時候表現爲沒有使用索引或者文件排序。

Handler_read_rnd_next 此選項代表在進行數據文件掃描時，從數據文件裏取數據的次數。

 

 

mysql> show global status like '%com_select%';

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

| Variable_name | Value |

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

| Com_select    | 1137  |

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

1 row in set (0.00 sec)

 

計算表掃描率：

表掃描率 ＝ handler_read_rnd_next / com_select

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