一、innodb_buffer_pool_size
這個是Innodb最重要的參數， 這個參數主要緩存innodb表的索引，數據，插入數據時的緩衝。
如果是一個專用DB服務器，那麼他可以佔到內存的70%-80%。
設置方法，在my.cnf文件裏：
innodb_buffer_pool_size=4G
注意：
在Mysql5.7版本之前，調整innodb_buffer_pool_size大小必須在my.cnf配置裏修改，然後重啓mysql進程纔可以生效
vim /etc/my.cnf
#innodb
user=mysql
innodb_buffer_pool_size=6G **#對於專用的MySQL數據庫服務器，最大可以把該值設置成物理內存的80%。根據MySQL手冊，對於2G內存的機器，推薦值是1G（50%）。
innodb_log_file_size=4G #作用：指定在一個日誌組中，每個log的大小，注意：這個值分配的大小和數據庫的寫入速度，事務大小，異常重啓後的恢復有很大的關係。一般取256M可以兼顧性能和recovery的速度
innodb_log_buffer_size = 8M #log緩存大小，一般爲1-8M，默認爲1M，對於較大的事務，可以增大緩存大小。可設置爲4M或8M。
innodb_flush_log_at_trx_commit=2 **#該值對插入數據的速度影響非常大，設置爲2時插入10000條記錄只需要2秒，設置爲0時只需要1秒，而設置爲1時則需要229秒。
innodb_file_per_table=1 #使每個Innodb的表，有自已獨立的表空間。如刪除文件後可以回收那部分空間。默認是關閉的，建議打開（innodb_file_per_table=1），分配原則：只有使用不使用。但DB還需要有一個公共的表空間
innodb_file_io_threads=4 #作用：文件讀寫IO數，這個參數只在Windows上起作用。在Linux上只會等於4，默認即可！
innodb_flush_method=O_DIRECT #作用：Innodb和系統打交道的一個IO模型，分配原則：Windows不用設置。linux可以選擇：O_DIRECT 直接寫入磁盤，禁止系統Cache了
innodb_io_capacity=2000 #這個參數刷新髒頁數量和合並插入數量，改善磁盤IO處理能力
innodb_io_capacity_max=6000
innodb_lru_scan_depth=2000
innodb_thread_concurrency = 0 #推薦設置爲 2*(NumCPUs+NumDisks)，默認一般爲8
innodb_additional_mem_pool_size=16M #根據MySQL手冊，對於2G內存的機器，推薦值是20M，可適當增加。通常不用太大，如果不夠用，MySQL會在錯誤日誌中寫入一條警告信息
innodb_autoinc_lock_mode = 2
##################################################
# Binary log/replication（這裏主要是複製功能，也就是主從）
log-bin #二進制日誌
sync_binlog=1 #爲了在最大程序上保證複製的InnoDB事務持久性和一致性
sync_relay_log=1 #爲了在最大程序上保證複製的InnoDB事務持久性和一致性
relay-log-info-repository=TABLE #啓用此兩項,可用於實現在崩潰時保證二進制及從服務器安全的功能
master-info-repository=TABLE #啓用此兩項,可用於實現在崩潰時保證二進制及從服務器安全的功能
expire_logs_days=7 #設置清除日誌時間
binlog_format=ROW #行復制
transaction-isolation=READ-COMMITTED #mysql數據庫事務隔離，級別有四種(READ UNCOMMITTED,READ COMMITTED,REPEATABLE READ,SERIALIZABLE)
#################################################
#cache
tmp_table_size=512M
character-set-server=utf8
collation-server=utf8_general_ci
skip-external-locking
back_log=1024
key_buffer_size=1024M
thread_stack=256k
read_buffer_size=8M
thread_cache_size=64
query_cache_size=128M
max_heap_table_size=256M
query_cache_type=1
binlog_cache_size = 2M
table_open_cache=128
thread_cache=1024
thread_concurrency=8 #推薦設置爲服務器 CPU核數的2倍，默認爲8
wait_timeout=30
join_buffer_size = 1024M
sort_buffer_size = 8M
read_rnd_buffer_size = 8M
#################################################
#connect
max-connect-errors=100000
max-connections=1000
#################################################
explicit_defaults_for_timestamp=true
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
##################################################
#cache
#內部內存臨時表的最大值
tmp_table_size=512M
character-set-server=utf8
collation-server=utf8_general_ci
#即跳過外部鎖定
skip-external-locking
#MySQL能暫存的連接數量(根據實際設置)
back_log=1024
#指定索引緩衝區的大小,只對MyISAM表起作用,這裏寫上也沒有關係
key_buffer_size=1024M
#這條指令限定用於每個數據庫線程的棧大小
thread_stack=256k
#當一個查詢不斷地掃描某一個表,MySQL會爲它分配一段內存緩衝區
read_buffer_size=8M
#線程緩存
thread_cache_size=64
#查詢緩存大小
query_cache_size=128M
#內部內存臨時表的最大值,每個線程都要分配
max_heap_table_size=256M
#將查詢結果放入查詢緩存中
query_cache_type=1
#代表在事務過程中容納二進制日誌SQL語句的緩存大小
binlog_cache_size = 2M
#同樣是緩存表大小
table_open_cache=128
#緩存線程
thread_cache=1024
#推薦設置爲服務器 CPU核數的2倍
thread_concurrency=8
wait_timeout=30
#表和表聯接的緩衝區的大小
join_buffer_size = 1024M
#是一個connection級參數,在每個connection第一次需要使用這個buffer的時候,一次性分配設置的內存
sort_buffer_size=8M
#隨機讀取數據緩衝區使用內存
read_rnd_buffer_size = 8M
#connect
#是一個MySQL中與安全有關的計數器值,它負責阻止過多嘗試失敗的客戶端以防止暴力破解密碼
max-connect-errors=100000
#連接數
max-connections=1000
#開啓查詢緩存
explicit_defaults_for_timestamp=true
#mysql服務器能夠工作在不同的模式下,並能針對不同的客戶端以不同的方式應用這些模式
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
下面列出了對性能優化影響較大的主要變量，主要分爲連接請求的變量和緩衝區變量。
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
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_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打補丁：http://www.percona.com/docs/wiki/release:start，記得找對應的版本。
打開慢查詢日誌可能會對系統性能有一點點影響，如果你的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。
要查看死鎖，你要show engine innodb status\G;
在MySQL5.6版本，在my.cnf配置文件裏，加入
innodb_print_all_deadlocks = 1
就可以把死鎖信息打印到錯誤日誌裏
