Mysql重要配置引數的整理

cat /etc/my.cnf

 

 

 

下面列出了對效能最佳化影響較大的主要變數，主要分為連線請求的變數和緩衝區變數。

1.   連線請求的變數：

1)     max_connections

MySQL的最大連線數，增加該值增加mysqld 要求的檔案描述符的數量。如果伺服器的併發連線請求量比較大，建議調高此值，以增加並行連線數量，當然這建立在機器能支撐的情況下，因為如果連線數越多， 介於MySQL會為每個連線提供連線緩衝區，就會開銷越多的記憶體，所以要適當調整該值，不能盲目提高設值。

數值過小會經常出現ERROR 1040: Too many connections錯誤，可以過’conn%’萬用字元檢視當前狀態的連線數量，以定奪該值的大小。

show variables like ‘max_connections’ 最大連線數

show  status like ‘max_used_connections’響應的連線數

如下：

mysql> show variables like ‘max_connections‘;

+———————–+——-+

| Variable_name　| Value |

+———————–+——-+

| max_connections | 256　　|

+———————–+——-+

mysql> show status like ‘max%connections‘;

+———————–+——-+

| Variable_name　      | Value |

+—————————-+——-+

| max_used_connections | 256|

+—————————-+——-+

max_used_connections / max_connections * 100% （理想值≈ 85%） 

如果max_used_connections跟max_connections相同 那麼就是max_connections設定過低或者超過伺服器負載上限了，低於10%則設定過大。

2)     back_log

MySQL能暫存的連線數量。當主要MySQL執行緒在一個很短時間內得到非常多的連線請求，這就起作用。如果MySQL的連線資料達到 max_connections時，新來的請求將會被存在堆疊中，以等待某一連線釋放資源，該堆疊的數量即back_log，如果等待連線的數量超過 back_log，將不被授予連線資源。

back_log值指出在MySQL暫時停止回答新請求之前的短時間內有多少個請求可以被存在堆疊中。只有如果期望在一個短時間內有很多連線，你需要增加它，換句話說，這值對到來的TCP/IP連線的偵聽佇列的大小。

當觀察你主機程式列表（mysql> show full processlist），發現大量264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待連線程式時，就要加大back_log 的值了。

預設數值是50，可調優為128，對系統設定範圍為小於512的整數。 

3)     interactive_timeout

一個互動連線在被伺服器在關閉前等待行動的秒數。一個互動的客戶被定義為對mysql_real_connect()使用CLIENT_INTERACTIVE 選項的客戶。 

預設數值是28800，可調優為7200。 

2.   緩衝區變數

全域性緩衝：

4)     key_buffer_size

key_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤其是索引讀的速度。透過檢查狀態值 Key_read_requests和Key_reads，可以知道key_buffer_size設定是否合理。比例key_reads / key_read_requests應該儘可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。

key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內部的臨時磁碟表是MyISAM表，也要使用該值。可以使用檢查狀態值created_tmp_disk_tables得知詳情。

舉例如下：

mysql> show variables like ‘key_buffer_size‘;

+——————-+————+

| Variable_name | Value      |

+———————+————+

| key_buffer_size | 536870912 |

+———— ———-+————+

key_buffer_size為512MB，我們再看一下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%，設定在1/1000左右較好

預設配置數值是8388600(8M)，主機有4GB記憶體，可以調優值為268435456(256MB)。

5)     query_cache_size

使用查詢緩衝，MySQL將查詢結果存放在緩衝區中，今後對於同樣的SELECT語句（區分大小寫），將直接從緩衝區中讀取結果。

透過檢查狀態值Qcache_*，可以知道query_cache_size設定是否合理（上述狀態值可以使用SHOW STATUS LIKE ‘Qcache%’獲得）。如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩衝不夠的情況，如果Qcache_hits的值也 非常大，則表明查詢緩衝使用非常頻繁，此時需要增加緩衝大小；如果Qcache_hits的值不大，則表明你的查詢重複率很低，這種情況下使用查詢緩衝反 而會影響效率，那麼可以考慮不用查詢緩衝。此外，在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩衝。

 

與查詢緩衝有關的引數還有query_cache_type、query_cache_limit、query_cache_min_res_unit。

 

query_cache_type指定是否使用查詢緩衝，可以設定為0、1、2，該變數是SESSION級的變數。

query_cache_limit指定單個查詢能夠使用的緩衝區大小，預設為1M。

query_cache_min_res_unit是在4.1版本以後引入的，它指定分配緩衝區空間的最小單位，預設為4K。檢查狀態值 Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多，這就表明查詢結果都比較小，此時需要減小 query_cache_min_res_unit。

舉例如下：

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> 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　  |

+————————————–+—————+

查詢快取碎片率= 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％，命中率很差，可能寫操作比較頻繁吧，而且可能有些碎片。

每個連線的緩衝

6)    record_buffer_size

每個進行一個順序掃描的執行緒為其掃描的每張表分配這個大小的一個緩衝區。如果你做很多順序掃描，你可能想要增加該值。

預設數值是131072(128K)，可改為16773120 (16M)

7)     read_rnd_buffer_size

隨機讀緩衝區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀快取區。進行排序查詢時，MySQL會首先掃描一遍該緩衝，以避 免磁碟搜尋，提高查詢速度，如果需要排序大量資料，可適當調高該值。但MySQL會為每個客戶連線發放該緩衝空間，所以應儘量適當設定該值，以避免記憶體開 銷過大。

一般可設定為16M 

8)     sort_buffer_size

每個需要進行排序的執行緒分配該大小的一個緩衝區。增加這值加速ORDER BY或GROUP BY操作。

預設數值是2097144(2M)，可改為16777208 (16M)。

9)     join_buffer_size

聯合查詢操作所能使用的緩衝區大小

record_buffer_size，read_rnd_buffer_size，sort_buffer_size，join_buffer_size為每個執行緒獨佔，也就是說，如果有100個執行緒連線，則佔用為16M*100

10)  table_cache

表快取記憶體的大小。每當MySQL訪問一個表時，如果在表緩衝區中還有空間，該表就被開啟並放入其中，這樣可以更快地訪問表內容。透過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如 果你發現open_tables等於table_cache，並且opened_tables在不斷增長，那麼你就需要增加table_cache的值了 （上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設定成很大的值。如果設定得太高，可能會造成檔案描述符不足，從而造成效能 不穩定或者連線失敗。

1G記憶體機器，推薦值是128－256。記憶體在4GB左右的伺服器該引數可設定為256M或384M。

11)  max_heap_table_size

使用者可以建立的記憶體表(memory table)的大小。這個值用來計算記憶體表的最大行數值。這個變數支援動態改變，即set @max_heap_table_size=#

這個變數和tmp_table_size一起限制了內部記憶體表的大小。如果某個內部heap（堆積）表大小超過tmp_table_size，MySQL可以根據需要自動將記憶體中的heap表改為基於硬碟的MyISAM表。

12)  tmp_table_size

透過設定tmp_table_size選項來增加一張臨時表的大小，例如做高階GROUP BY操作生成的臨時表。如果調高該值，MySQL同時將增加heap表的大小，可達到提高聯接查詢速度的效果，建議儘量最佳化查詢，要確保查詢過程中生成的臨時表在記憶體中，避免臨時表過大導致生成基於硬碟的MyISAM表。

mysql> show global status like ‘created_tmp%‘;

+——————————–+———+

| Variable_name　　           | Value　|

+———————————-+———+

| Created_tmp_disk_tables | 21197  |

| Created_tmp_files　　　| 58　　|

| Created_tmp_tables　　| 1771587 |

+——————————–+———–+

每次建立臨時表，Created_tmp_tables增加，如果臨時表大小超過tmp_table_size，則是在磁碟上建立臨時 表，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%，應該相當好了

預設為16M，可調到64-256最佳，執行緒獨佔，太大可能記憶體不夠I/O堵塞

13)  thread_cache_size

可以複用的儲存在中的執行緒的數量。如果有，新的執行緒從快取中取得，當斷開連線的時候如果有空間，客戶的線置在快取中。如果有很多新的執行緒，為了提高效能可以這個變數值。

透過比較 Connections和Threads_created狀態的變數，可以看到這個變數的作用。

預設值為110，可調優為80。 

14)  thread_concurrency

推薦設定為伺服器 CPU核數的2倍，例如雙核的CPU, 那麼thread_concurrency的應該為4；2個雙核的cpu, thread_concurrency的值應為8。預設為8

15)  wait_timeout

指定一個請求的最大連線時間，對於4GB左右記憶體的伺服器可以設定為5-10。

 

3.    配置InnoDB的幾個變數

innodb_buffer_pool_size

對於InnoDB表來說，innodb_buffer_pool_size的作用就相當於key_buffer_size對於MyISAM表的作用一樣。InnoDB使用該引數指定大小的記憶體來緩衝資料和索引。對於單獨的MySQL資料庫伺服器，最大可以把該值設定成實體記憶體的80%。

根據MySQL手冊，對於2G記憶體的機器，推薦值是1G（50%）。

 

innodb_flush_log_at_trx_commit

主要控制了innodb將log buffer中的資料寫入日誌檔案並flush磁碟的時間點，取值分別為0、1、2三個。0，表示當事務提交時，不做日誌寫入操作，而是每秒鐘將log buffer中的資料寫入日誌檔案並flush磁碟一次；1，則在每秒鐘或是每次事物的提交都會引起日誌檔案寫入、flush磁碟的操作，確保了事務的 ACID；設定為2，每次事務提交引起寫入日誌檔案的動作，但每秒鐘完成一次flush磁碟操作。

實際測試發現，該值對插入資料的速度影響非常大，設定為2時插入10000條記錄只需要2秒，設定為0時只需要1秒，而設定為1時則需要229秒。因此，MySQL手冊也建議儘量將插入操作合併成一個事務，這樣可以大幅提高速度。

根據MySQL手冊，在允許丟失最近部分事務的危險的前提下，可以把該值設為0或2。

 

innodb_log_buffer_size

log快取大小，一般為1-8M，預設為1M，對於較大的事務，可以增大快取大小。

可設定為4M或8M。

 

innodb_additional_mem_pool_size

該引數指定InnoDB用來儲存資料字典和其他內部資料結構的記憶體池大小。預設值是1M。通常不用太大，只要夠用就行，應該與表結構的複雜度有關係。如果不夠用，MySQL會在錯誤日誌中寫入一條警告資訊。

根據MySQL手冊，對於2G記憶體的機器，推薦值是20M，可適當增加。

 

innodb_thread_concurrency=8

推薦設定為 2*(NumCPUs+NumDisks)，預設一般為8

 

 

MySQL 5.6相比於前代GA版本效能提升顯著，但預設快取設定對於小型站點並不合理。透過修改my.ini檔案中的performance_schema_max_table_instances引數，能夠有效降低記憶體佔用。

 

以下是5.6預設的設定

performance_schema_max_table_instances 12500

table_definition_cache 1400

table_open_cache 2000

可以調成，或者在小點都可以。

 

performance_schema_max_table_instances=600

table_definition_cache=400

table_open_cache=256

performance_schema_max_table_instances

The maximum number of instrumented table objects  檢測的表物件的最大數目。

table_definition_cache
The number of table definitions (from .frm files) that can be stored in the definition cache. If you use a large number of tables, you can create a large table definition cache to speed up opening of tables. The table definition cache takes less space and does not use file descriptors, unlike the normal table cache. The minimum and default values are both 400. 
快取frm檔案

table_open_cache
The number of open tables for all threads. Increasing this value increases the number of file descriptors that mysqld requires. 

table_open_cache指的是快取資料檔案的描述符(Linux/Unix)相關資訊

這個很重要啊，之前mount個單獨的檔案，資料庫一直不成功，原來是這個在作怪啊。

chcon -R -t mysqld_db_t /home/myusqldata

 

網上的太多了，都不知道哪個是原創了：我找的是

 

mysql> show variables;

一、慢查詢

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 |
+---------------------+-------+

配置中開啟了記錄慢查詢，執行時間超過2秒的即為慢查詢，系統顯示有4148個慢查詢，你可以分析慢查詢日誌，找出有問題的SQL語句，慢查詢時間不宜設定過長，否則意義不大，最好在5秒以內，如果你需要微秒級別的慢查詢，可以考慮給MySQL打補丁：，記得找對應的版本。
開啟慢查詢日誌可能會對系統效能有一點點影響，如果你的MySQL是主－從結構，可以考慮開啟其中一臺從伺服器的慢查詢日誌，這樣既可以監控慢查詢，對系統效能影響又小。
二、連線數
經常會遇見”MySQL: ERROR 1040: Too manyconnections”的情況，一種是訪問量確實很高，MySQL伺服器抗不住，這個時候就要考慮增加從伺服器分散讀壓力，另外一種情況是MySQL配置檔案中max_connections值過小：

mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 256 |
+-----------------+-------+

這臺MySQL伺服器最大連線數是256，然後查詢一下伺服器響應的最大連線數：

mysql> show global status like 'Max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 245 |
+----------------------+-------+

MySQL伺服器過去的最大連線數是245，沒有達到伺服器連線數上限256，應該沒有出現1040錯誤，比較理想的設定是：

Max_used_connections / max_connections   * 100% ≈ 85%

最大連線數占上限連線數的85％左右，如果發現比例在10%以下，MySQL伺服器連線數上限設定的過高了。
三、Key_buffer_size
key_buffer_size是對MyISAM表效能影響最大的一個引數，下面一臺以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%

比 如上面的資料，key_cache_miss_rate為0.0244%，4000個索引讀取請求才有一個直接讀硬碟，已經很BT 了，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_blocks_u%';
+------------------------+-------------+
| Variable_name       | Value    |
+------------------------+-------------+
| Key_blocks_unused    | 0           |
| Key_blocks_used        | 413543    |
+------------------------+-------------+

Key_blocks_unused 表示未使用的快取簇(blocks)數，Key_blocks_used表示曾經用到的最大的blocks數，比如這臺伺服器，所有的快取都用到了，要麼 增加key_buffer_size，要麼就是過渡索引了，把快取佔滿了。比較理想的設定：

Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

四、臨時表

mysql> show global status like 'created_tmp%';
+-------------------------+---------+
| Variable_name           | Value |
+-------------------------+---------+
| Created_tmp_disk_tables | 21197 |
| Created_tmp_files    | 58    |
| Created_tmp_tables    | 1771587 |
+-------------------------+---------+

每次建立臨時表，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 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以下的臨時表才能全部放記憶體，超過的就會用到硬碟臨時表。
五、Open Table情況

mysql> show global status like 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 919 |
| Opened_tables | 1951   |
+---------------+-------+

Open_tables 表示開啟表的數量，Opened_tables表示開啟過的表數量，如果Opened_tables數量過大，說明配置中 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%

六、程式使用情況

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，當客戶端斷開之後，伺服器處理此客戶的執行緒將會快取起來以響應下一個客戶 而不是銷燬（前提是快取數未達上限）。Threads_created表示建立過的執行緒數，如果發現Threads_created值過大的話，表明 MySQL伺服器一直在建立執行緒，這也是比較耗資源，可以適當增加配置檔案中thread_cache_size值，查詢伺服器 thread_cache_size配置：

mysql> show variables like 'thread_cache_size';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| thread_cache_size | 64 |
+-------------------+-------+

示例中的伺服器還是挺健康的。
七、查詢快取(query cache)

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：快取中相鄰記憶體塊的個數。數目大說明可能有碎片。FLUSH QUERY CACHE會對快取中的碎片進行整理，從而得到一個空閒塊。
Qcache_free_memory：快取中的空閒記憶體。
Qcache_hits：每次查詢在快取中命中時就增大
Qcache_inserts：每次插入一個查詢時就增大。命中次數除以插入次數就是不中比率。
Qcache_lowmem_prunes： 快取出現記憶體不足並且必須要進行清理以便為更多查詢提供空間的次數。這個數字最好長時間來看；如果這個數字在不斷增長，就表示可能碎片非常嚴重，或者記憶體 很少。（上面的 free_blocks和free_memory可以告訴您屬於哪種情況）
Qcache_not_cached：不適合進行快取的查詢的數量，通常是由於這些查詢不是 SELECT 語句或者用了now()之類的函式。
Qcache_queries_in_cache：當前快取的查詢（和響應）的數量。
Qcache_total_blocks：快取中塊的數量。

我們再查詢一下伺服器關於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，設定值大對大資料查詢有好處，但如果你的查詢都是小資料查詢，就容易造成記憶體碎片和浪費。

查詢快取碎片率 = 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％，命中率很差，可能寫操作比較頻繁吧，而且可能有些碎片。
八、排序使用情況

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 首先會嘗試在記憶體中做排序，使用的記憶體大小由系統變數Sort_buffer_size 決定，如果它的大小不夠把所有的記錄都讀到記憶體中，MySQL 就會把每次在記憶體中排序的結果存到臨時檔案中，等MySQL 找到所有記錄之後，再把臨時檔案中的記錄做一次排序。這再次排序就會增加 Sort_merge_passes。實際上，MySQL會用另一個臨時檔案來存再次排序的結果，所以通常會看到 Sort_merge_passes增加的數值是建臨時檔案數的兩倍。因為用到了臨時檔案，所以速度可能會比較慢，增加 Sort_buffer_size 會減少Sort_merge_passes 和 建立臨時檔案的次數。但盲目的增加 Sort_buffer_size 並不一定能提高速度，
另外，增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值對排序的操作也有一點的好處，
九、檔案開啟數(open_files)

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％
十、表鎖情況

mysql> show global status like 'table_locks%';
+-----------------------+-----------+
| Variable_name       | Value     |
+-----------------------+-----------+
| Table_locks_immediate | 490206328 |
| Table_locks_waited | 2084912 |
+-----------------------+-----------+

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就足夠了。
十一、表掃描情況

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 |
+-----------------------+-------------+

各欄位解釋參見,調出伺服器完成的查詢請求次數：

mysql> show global status like 'com_select';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| Com_select | 222693559 |
+---------------+-----------+

計算表掃描率：

表掃描率 ＝ Handler_read_rnd_next / Com_select

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