mysql的監控方法大體分爲兩類：
1.鏈接到mysql數據庫內部，使用show status，show variables，flush status 來查看mysql的各類性能指標。
2. 直接使用mysqladmin查看其性能指標，例如：
UserParameter=mysql.uptime,mysqladmin -uroot status|cut -f2 -d":"|cut -f1 -d"T"
mysqladmin兩個參數，status，extended-status
shell > mysqladmin -uroot -ppassword variables status
可獲得如下信息（後面詳解）
--------------------------------------------------------------------------------------------------------------------------
Uptime: 4557887 #mysql運行的秒數
Threads: 1 #鏈接數
Questions: 1684130 #The number of questions (queries) from clients since the server was started.
Slow queries: 0 #The number of queries that have taken more than long_query_time seconds
Opens: 221872 #The number of tables the server has opened.
Flush tables: 1 #The number of flush-*, refresh, and reload commands the server has executed.
Open tables: 64 #The number of tables that currently are open.
Queries per second avg: 0.369 #從上次運行開始計算，每秒鐘平均查詢次數
-----------------------------------------------------------------------------------------------------
Questions = Com_* + Qcache_hits
最完整的信息
shell > mysqladmin -uroot -ppassword variables extended-status
其餘的信息
shell > /usr/libexec/mysqld --verbose --help （這個命令生成全部mysqld選項和可配置變量的列表 ）
mysql>SHOW STATUS; （服務器狀態變量，運行服務器的統計和狀態指標）
mysql> SHOW VARIABLES;（服務器系統變量，實際上使用的變量的值）
或者
mysql>SHOW STATUS LIKE '%變量名% ' ;
對配置參數的說明：
配置參數的格式以下：（shell > mysqladmin -uroot -ppassword variables extended-status）
-----------------------------
+-----------------------------------------+------------------------------------------------------------+
| Variable_name | Value |
+-----------------------------------------+------------------------------------------------------------+
| auto_increment_increment | 1 |
| auto_increment_offset | 1 |
| automatic_sp_privileges | ON |
.........
注：value 值的單位是byte ，要獲得M ，需除以2次1024
-----------------------------------
Uptime 4405546
MySQL服務器已經運行的秒數
-----------------------------------
auto_increment_increment 1
auto_increment_offset 1
兩個變量值都只能爲1到65,535之間的整數值。設置爲非整數值，則會給出錯誤。
這兩個變量影響AUTO_INCREMENT列。
auto_increment_increment控制列中的值的增量值（步進量）。
auto_increment_offset肯定AUTO_INCREMENT列值的初始值。
通常不去更改。更改方法：mysql> SET @auto_increment_offset=5;
-----------------------------------------------------------------------------------------------------
max_connections 100
table_cache 64
open_files_limit 1024
Open_tables 64
Opened_tables 187690
幾個參數的關係：
table_cache * 2 + max_connections＝max_open_files
max_connections
默認爲100
mysql>show processlist;
mysql>show full processlist;
-----------------------
-------------------------
max_open_files 由 open_files_limit 參數決定。
mysql打開的最大文件數，受兩個參數的影響：系統打開的最大文件數（ulimit -n）和 open_files_limit 。
加大max_open_files的值
-------------------------------------------------------------
在/etc/my.cnf加入open_files_limit=8192
在/etc/security/limits.conf添加
* soft nofile 8192
* hard nofile 8192
--------------------------------------------------------------------
最好用sysctl或者修改/etc/sysctl.conf文件，同時還要在配置文件中把open_files_limit這個參數增大，對於4G內存服務器，open_files_limit至少要增大到4096，非特殊狀況，設置成8192就能夠了。
table_cache
MySQL 5.0升級到5.1，table_cache 更名table_open_cache
設置表高速緩存的數目。
表緩存的說明：
當 Mysql 訪問一個表時，若是該表在緩存中已經被打開，則能夠直接訪問緩存；若是尚未被緩存，可是在 Mysql 表緩衝區中還有空間，那麼這個表就被打開並放入表緩衝區；若是表緩存滿了，則會按照必定的規則將當前未用的表釋放，或者臨時擴大表緩存來存放，使用表緩存的好處是能夠更快速地訪問表中的內容。
每一個鏈接進來，都會至少打開一個表緩存。所以， table_cache 的大小應與 max_connections 的設置有關。例如，對於 200 個並行運行的鏈接，應該讓表的緩存至少有 200 × N ，這裏 N 是網站程序一次查詢所用到的表的最大值。
每一個線程會獨自持有一個數據文件的文件描述符，而索引文件的文件描述符是公用的。當table cache不夠用的時候，MySQL會採用LRU算法踢掉最長時間沒有使用的表。若是table_cache設置太小，MySQL就會反覆打開、關閉 frm文件，形成必定的性能損失。若是table_cache設置過大，MySQL將會消耗不少CPU去作 table cache的算法運算。
而InnoDB的元數據管理是放在共享表空間裏面作的，因此獲取表的結構不須要去反覆解析frm文件，這是比MyISAM強的地方。即便 table_cache設置太小，對於InnoDB的影響也是很小的，由於它根本不須要反覆打開、關閉frm文件去獲取元數據。
合理設置table_cache的大小：經過查看open_tables，Opened_tables，Flush tables 的值來比較。
察看當前的表緩存狀況：
shell > mysqladmin -uroot -ppassword variables status
----------------------------------
Opens: 221872 則是已經打開的表的數量。
Flush tables: 1
Open tables: 64 是當前打開的表的數量
----------------------------------
mysql> show global status like 'open%_tables';
----------------------------------
open_tables 是當前打開的表的數量，
Opened_tables 表示打開過的表數量
----------------------------------
清空表緩存
mysql> flush tables;
若是發現 open_tables 接近 table_cache 的時候，若是 Opened_tables 隨着從新運行 SHOW STATUS 命令快速增長，就說明緩存命中率不夠。而且屢次執行FLUSH TABLES(經過shell > mysqladmin -uroot -ppassword variables status )，那就說明可能 table_cache 設置的偏小，常常須要將緩存的表清出，將新的表放入緩存，這時能夠考慮增長這個參數的大小來改善訪問的效率。
若是 Open_tables 比 table_cache 設置小不少，就說明table_cache 設的太大了。
table_cache的值在2G內存如下的機器中的值默認時256到512，若是機器有4G內存,則默認這個值是2048，但這決意味着機器內存越大，這個值應該越大，由於table_cache加大後，使得mysql對SQL響應的速度更快了，不可避免的會產生更多的死鎖（dead lock），這樣反而使得數據庫整個一套操做慢了下來，嚴重影響性能。
注意，不能盲目地把table_cache設置成很大的值。若是設置得過高，可能會形成文件描述符不足，從而形成性能不穩定或者鏈接失敗。
對於有1G內存的機器，推薦值是128－256。
--------------------------------------------------------------------
key_buffer_size 67108864（/1024/1024=64M）
Key_read_requests 40944 從緩存讀鍵的數據塊的請求數。
Key_reads 2711 從硬盤讀取鍵的數據塊的次數。
Key_write_requests 將鍵的數據塊寫入緩存的請求數。
Key_writes 向硬盤寫入將鍵的數據塊的物理寫操做的次數。
（得到信息：
shell > mysqladmin -uroot -ppassword variables extended-status
shell>mysqladmin -uroot -ppassword variable status
mysql> show status like '%key_read%';
）
key_buffer_size設置索引塊（index blocks）緩存的大小，保存了 MyISAM 表的索引塊。它被全部線程共享，決定了數據庫索引處理的速度，尤爲是索引讀的速度。理想狀況下，對於這些塊的請求應該來自於內存，而不是來自於磁盤。
只對MyISAM表起做用。即便你不使用MyISAM表，可是內部的臨時磁盤表是MyISAM表，也要使用該值。
key_buffer_size: 若是不使用MyISAM存儲引擎，16MB足以，用來緩存一些系統表信息等。若是使用 MyISAM存儲引擎，在內存容許的狀況下，儘量將全部索引放入內存，簡單來講就是「越大越好」
合理設置key_buffer_size的方法：
查看Key_read_requests和Key_reads的比例，
Key_reads 表明命中磁盤的請求個數， Key_read_requests 是總數。命中磁盤的讀請求數除以讀請求總數就是不中比率。若是每 1,000 個請求中命中磁盤的數目超過 1 個，就應該考慮增大關鍵字緩衝區了。
key_reads / key_read_requests的值應該儘量的低，好比1:100，1:1000 ，1:10000。
對於內存在4GB左右的服務器該參數可設置爲256M或384M。
注意：該參數值設置的過大反而會是服務器總體效率下降！
--------------------------------------------------------------------------------------------------------
256MB內存和許多表，想要在中等數量的客戶時得到最大性能，應使用：
shell> mysqld_safe --key_buffer_size=64M --table_cache=256 --sort_buffer_size=4M --read_buffer_size=1M &
-------------------------------------------------------------------------------------------------------------------------------------------------------
每一個鏈接到MySQL服務器的線程都須要有本身的緩衝，默認爲其分配256K。事務開始以後，則須要增長更多的空間。運行較小的查詢可能僅給指定的線程增長少許的內存消耗，例如存儲查詢語句的空間等。但若是對數據表作複雜的操做比較複雜，例如排序則須要使用臨時表，此時會分配大約read_buffer_size，sort_buffer_size，read_rnd_buffer_size，tmp_table_size大小的內存空間。不過它們只是在須要的時候才分配，而且在那些操做作完以後就釋放了。
myisam_sort_buffer_size 8388608
當在REPAIR TABLE或用CREATE INDEX建立索引或ALTER TABLE過程當中排序 MyISAM索引分配之緩衝區。
sort_buffer_size 2097144
每一個排序線程分配的緩衝區的大小。增長該值能夠加快ORDER BY或GROUP BY操做。
注意：該參數對應的分配內存是每一個鏈接獨享，若是有100個鏈接，那麼實際分配的總共排序緩衝區大小爲100 × 6 ＝ 600MB。因此，對於內存在4GB左右的服務器推薦設置爲6-8M。
mysql> SHOW STATUS LIKE "sort%";
---------------------------
Sort_merge_passes 1
Sort_range 79192
Sort_rows 2066532
Sort_scan 44006
---------------------------
若是 sort_merge_passes 很大，就表示須要注意 sort_buffer_size。
當 MySQL 必需要進行排序時，就會在從磁盤上讀取數據時分配一個排序緩衝區來存放這些數據行。若是要排序的數據太大，那麼數據就必須保存到磁盤上的臨時文件中，並再次進行排序。若是 sort_merge_passes 狀態變量很大，這就指示了磁盤的活動狀況。
read_buffer_size 131072
（show variables like 'read%';）
----------------
read_buffer_size 1048576
read_rnd_buffer_size 524288
---------------
read_buffer_size是MySql讀入緩衝區大小。對錶進行順序掃描的請求將分配一個讀入緩衝區，MySql會爲它分配一段內存緩衝區。read_buffer_size變量控制這一緩衝區的大小。
每一個線程連續掃描時爲掃描的每一個表分配的緩衝區的大小(字節)。若是進行屢次連續掃描，可能須要增長該值， 默認值爲131072。和sort_buffer_size同樣，該參數對應的分配內存也是每鏈接獨享。
read_rnd_buffer_size
read_rnd_buffer_size是MySql的隨機讀緩衝區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩衝，以免磁盤搜索，提升查詢速度，若是須要排序大量數據，可適當調高該值。該參數對應的分配內存也是每鏈接獨享。
join_buffer_size 131072
聯合查詢操做所能使用的緩衝區大小，和sort_buffer_size同樣，該參數對應的分配內存也是每一個鏈接獨享。
--------------------------------------------------------------------------------------------------------
max_allowed_packet 1048576
net_buffer_length 16384
包消息緩衝區初始化爲net_buffer_length字節，但須要時能夠增加到max_allowed_packet字節。該值默認很小，以捕獲大的(多是錯誤的)數據包。
--------------------------------------------------------------------------------------------------------
thread_stack 196608
每一個線程的堆棧大小。用crash-me測試檢測出的許多限制取決於該值。 默認值足夠大，能夠知足普通操做。
--------------------------------------------------------------------------------------------------------
thread_cache_size 0
query_cache_size 0
tmp_table_size 33554432
innodb_thread_concurrency 8
max_connections 100
max_connect_errors 10
（得到信息：
shell > mysqladmin -uroot -ppassword variables extended-status
shell>mysqladmin -uroot -ppassword variable status
）
thread_cache_size
（
mysql> show status LIKE 'threads%';
）
---------------------------
Threads_cached 27
Threads_connected 15
Threads_created 838610
Threads_running 3
----------------------------
線程緩存。mysqld 在接收鏈接時會根據須要生成線程。在一個鏈接變化很快的繁忙服務器上，對線程進行緩存便於之後使用能夠加快最初的鏈接。
此處重要的值是 Threads_created，每次 mysqld 須要建立一個新線程時，這個值都會增長。若是這個數字在連續執行 SHOW STATUS 命令時快速增長，就應該嘗試增大線程緩存。
query_cache_size
mysql> SHOW VARIABLES LIKE 'have_query_cache';
mysql> show variables like '%query%';
------------------------------------
ft_query_expansion_limit 20
have_query_cache YES
long_query_time 10.000000
query_alloc_block_size 8192
query_cache_limit 1048576
query_cache_min_res_unit 4096
query_cache_size 0
query_cache_type ON
query_cache_wlock_invalidate OFF
query_prealloc_size 8192
slow_query_log OFF
slow_query_log_file /var/run/mysqld/mysqld-slow.log
-------------------------------------
have_query_cache 是否有查詢緩存
query_cache_limit 指定單個查詢可以使用的緩衝區大小，缺省爲1M
query_cache_type 變量影響其工做方式。這個變量能夠設置爲下面的值：
0 或OFF 將阻止緩存或查詢緩存結果。
1 或ON 將容許緩存，以SELECT SQL_NO_CACHE 開始的查詢語句除外。
2 或DEMAND ， 僅對以SELECT SQL_CACHE 開始的那些查詢語句啓用緩存。
若是所有使用innodb存儲引擎，建議爲0，若是使用MyISAM 存儲引擎，建議爲2
query_cache_min_res_unit 是在4.1版本之後引入的，它指定分配緩衝區空間的最小單位，缺省爲4K。檢查狀態值Qcache_free_blocks，若是該值很是大，則代表緩衝區中碎片不少，這就代表查詢結果都比較小，此時須要減少 query_cache_min_res_unit。
query_cache_size 爲了存儲老的查詢結果而分配的內存數量 (以字節指定) 。若是設置它爲 0 ，查詢緩衝將被禁止(缺省值爲 0 )。 根據 命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))進行調整，通常不建議太大，256MB可能已經差很少了，大型的配置型靜態數據可適當調大
mysql> SHOW STATUS LIKE 'qcache%';
---------------------------------------
Qcache_free_blocks 5216
Qcache_free_memory 14640664
Qcache_hits 2581646882
Qcache_inserts 360210964
Qcache_lowmem_prunes 281680433
Qcache_not_cached 79740667
Qcache_queries_in_cache 16927
Qcache_total_blocks 47042
-----------------------------------------
Qcache_free_blocks 緩存中相鄰內存塊的個數。數目大說明可能有碎片。FLUSH QUERY CACHE 會對緩存中的碎片進行整理，從而獲得一個空閒塊。
Qcache_free_memory 緩存中的空閒內存。
Qcache_hits 每次查詢在緩存中命中時就增大。
Qcache_inserts 每次插入一個查詢時就增大。 未命中而後插入。
Qcache_lowmem_prunes 的值很是大，則代表常常出現緩衝不夠的狀況,同時Qcache_hits的值很是大，則代表查詢緩衝使用很是頻繁，此時須要增長緩衝大小，Qcache_hits的值不大，則代表你的查詢重複率很低，這種狀況下使用查詢緩衝反而會影響效率，那麼能夠考慮不用查詢緩衝。這個數字最好長時間來看；若是這個數字在不斷增加，就表示可能碎片很是嚴重，或者內存不多。（上面的 free_blocks 和 free_memory 能夠告訴您屬於哪一種狀況）。
Qcache_not_cached 不適合進行緩存的查詢的數量，一般是因爲這些查詢不是 SELECT 語句。
Qcache_queries_in_cache 當前緩存的查詢（和響應）的數量。
Qcache_total_blocks 緩存中塊的數量。
Total number of queries = Qcache_inserts + Qcache_hits + Qcache_not_cached.
查詢命中率=Qcache_hits -Qcache_inserts /Qcache_hits
查詢插入率=Qcache_inserts / Com_select;
未插入率 = Qcache_not_cached / Com_select;
不少 LAMP 應用程序都嚴重依賴於數據庫，但卻會反覆執行相同的查詢。每次執行查詢時，數據庫都必需要執行相同的工做 —— 對查詢進行分析，肯定如何執行查詢，從磁盤中加載信息，而後將結果返回給客戶機。MySQL 有一個特性稱爲查詢緩存，查詢緩存會存儲一個 SELECT 查詢的文本與被傳送到客戶端的相應結果。若是以後接收到一個一樣的查詢，服務器將從查詢緩存中檢索結果，而不是再次分析和執行這個一樣的查詢。在不少狀況下，這會極大地提升性能。不過，問題是查詢緩存在默認狀況下是禁用的。
一般，間隔幾秒顯示這些變量就能夠看出區別，這能夠幫助肯定緩存是否正在有效地使用。運行 FLUSH STATUS 能夠重置一些計數器，若是服務器已經運行了一段時間，這會很是有幫助。
使用很是大的查詢緩存，指望能夠緩存全部東西，這種想法很是誘人。但若是表有變更時，首先要把Query_cache和該表相關的語句所有置爲失效，而後在寫入更新。
那麼若是Query_cache很是大，該表的查詢結構又比較多，查詢語句失效也慢，一個更新或是Insert就會很慢，這樣看到的就是Update或是Insert怎麼這麼慢了。
因此在數據庫寫入量或是更新量也比較大的系統，該參數不適合分配過大。並且在高併發，寫入量大的系統，建系把該功能禁掉。
做爲一條規則，若是 FLUSH QUERY CACHE 佔用了很長時間，那就說明緩存太大了。
--------------------------------------------------------------------------------------------------------
wait_timeout 28800
服務器關閉非交互鏈接以前等待活動的秒數。
在線程啓動時，根據全局wait_timeout值或全局interactive_timeout值初始化會話wait_timeout值，取決於客戶端類型
connect_timeout 10
mysqld服務器用Bad handshake響應前等待鏈接包的秒數。
interactive_timeout 28800
服務器關閉交互式鏈接前等待活動的秒數。交互式客戶端定義爲在mysql_real_connect()中使用CLIENT_INTERACTIVE選項的客戶端。
--------------------------------------------------------------------------------------------------------
mysql> SHOW STATUS LIKE "com_select";
-------------------------------
Com_select 318243
-------------------------------
mysql> SHOW STATUS LIKE "handler_read_rnd_next";
-------------------------------
Handler_read_rnd_next 165959471
-----------------------------------
MySQL 也會分配一些內存來讀取表。理想狀況下，索引提供了足夠多的信息，能夠只讀入所須要的行，可是有時候查詢（設計不佳或數據本性使然）須要讀取表中大量數據。要理解這種行爲，須要知道運行了多少個 SELECT 語句，以及須要讀取表中的下一行數據的次數（而不是經過索引直接訪問）。
Handler_read_rnd_next / Com_select 得出了表掃描比率 —— 在本例中是 521:1。若是該值超過 4000，就應該查看 read_buffer_size，例如 read_buffer_size = 4M。若是這個數字超過了 8M，就應該與開發人員討論一下對這些查詢進行調優了！
--------------------------------------------------------------------------------------------------------
mysql> SHOW STATUS LIKE 'created_tmp%';
------------------------
Created_tmp_disk_tables 30660
Created_tmp_files 2
Created_tmp_tables 32912
---------------------
臨時表能夠在更高級的查詢中使用，其中數據在進一步進行處理（例如 GROUP BY 字句）以前，都必須先保存到臨時表中；理想狀況下，在內存中建立臨時表。可是若是臨時表變得太大，就須要寫入磁盤中。
每次使用臨時表都會增大 Created_tmp_tables；基於磁盤的表也會增大 Created_tmp_disk_tables。對於這個比率，並無什麼嚴格的規則，由於這依賴於所涉及的查詢。長時間觀察 Created_tmp_disk_tables 會顯示所建立的磁盤表的比率，您能夠肯定設置的效率。 tmp_table_size 和 max_heap_table_size 均可以控制臨時表的最大大小，所以請確保在 my.cnf 中對這兩個值都進行了設置。
-------------------------------------------------------------------------------------------------------
日誌相關
log-bin=mysql-bin
binlog_format=mixed
mysql-bin.00000一、mysql-bin.000002等文件是數據庫的操做日誌，例如UPDATE一個表，或者DELETE一些數據，即便該語句沒有匹配的數據，這個命令也會存儲到日誌文件中，還包括每一個語句執行的時間，也會記錄進去的。
=================================================================================================
InnoDB
innodb_buffer_pool_size
innodb_buffer_pool_size 定義了 InnoDB 存儲引擎的表數據和索引數據的最大內存緩衝區大小。和 MyISAM 存儲引擎不一樣， MyISAM 的 key_buffer_size 只能緩存索引鍵，而 innodb_buffer_pool_size 卻能夠緩存數據塊和索引鍵。適當的增長這個參數的大小，能夠有效的減小 InnoDB 類型的表的磁盤 I/O 。爲Innodb加速優化首要參數。默認值8M
這個參數不能動態更改，因此分配需多考慮。分配過大，會使Swap佔用過多，導致Mysql的查詢特慢。若是你的數據量不大，而且不會暴增，那麼可分配是你的數據大小＋１０％左右作爲這個參數的值。例如：數據大小爲50M,那麼給這個值分配innodb_buffer_pool_size＝64M
mysql>show variables like 'innodb%';
---------------------
innodb_adaptive_hash_index ON
innodb_additional_mem_pool_size 2097152
innodb_autoextend_increment 8
innodb_autoinc_lock_mode 1
innodb_buffer_pool_size 67108864
innodb_checksums ON
innodb_commit_concurrency 0
innodb_concurrency_tickets 500
innodb_data_file_path ibdata1:10M:autoextend
innodb_data_home_dir /var/lib/mysql
innodb_doublewrite ON
innodb_fast_shutdown 1
innodb_file_io_threads 4
innodb_file_per_table OFF
innodb_flush_log_at_trx_commit 1
innodb_flush_method
innodb_force_recovery 0
innodb_lock_wait_timeout 50
innodb_locks_unsafe_for_binlog OFF
innodb_log_buffer_size 8388608
innodb_log_file_size 16777216
innodb_log_files_in_group 2
innodb_log_group_home_dir /var/lib/mysql
innodb_max_dirty_pages_pct 90
innodb_max_purge_lag 0
innodb_mirrored_log_groups 1
innodb_open_files 300
innodb_rollback_on_timeout OFF
innodb_stats_method nulls_equal
innodb_stats_on_metadata ON
innodb_support_xa ON
innodb_sync_spin_loops 20
innodb_table_locks ON
innodb_thread_concurrency 8
innodb_thread_sleep_delay 10000
innodb_use_legacy_cardinality_algorithm ON
----------------------
mysql>show status like 'innodb%';
----------------
Innodb_buffer_pool_pages_data 2559 分配出去， 正在被使用頁的數量，包括髒頁。單位是page
Innodb_buffer_pool_pages_dirty 0 髒頁但沒有被flush除去的頁面數。單位是page
Innodb_buffer_pool_pages_flushed 795 已經flush的頁面數。單位是page
Innodb_buffer_pool_pages_free 1473 當前空閒頁面數。單位是page
Innodb_buffer_pool_pages_misc 64 緩存池中當前已經被用做管理用途或hash index而不能用做爲普通數據頁的數目。單位是page
Innodb_buffer_pool_pages_total 4096 緩衝區總共的頁面數。單位是page
Innodb_buffer_pool_read_ahead_rnd 8 隨機預讀的次數
Innodb_buffer_pool_read_ahead_seq 1 順序預讀的次數
Innodb_buffer_pool_read_requests 1725871 從緩衝池中讀取頁的次數
Innodb_buffer_pool_reads 2108 從磁盤讀取頁的次數。緩衝池裏面沒有， 就會從磁盤讀取
Innodb_buffer_pool_wait_free 0 緩衝池等待空閒頁的次數，當須要空閒塊而系統中沒有時，就會等待空閒頁面
Innodb_buffer_pool_write_requests 2296 緩衝池總共發出的寫請求次數
Innodb_data_fsyncs 695 總共完成的fsync次數
Innodb_data_pending_fsyncs 0 innodb當前等待的fsync次數
Innodb_data_pending_reads 0 innodb當前等待的讀的次數
Innodb_data_pending_writes 0 innodb當前等待的寫的次數
Innodb_data_read 44044288 總共讀入的字節數
Innodb_data_reads 2191 innodb完成的讀的次數
Innodb_data_writes 1296 innodb完成的寫的次數
Innodb_data_written 26440192 總共寫出的字節數
Innodb_dblwr_pages_written 795
Innodb_dblwr_writes 90
Innodb_log_waits 0 因日誌緩存過小而必須等待其被寫入所形成的等待數。單位是次。
Innodb_log_write_requests 263
Innodb_log_writes 410
Innodb_os_log_fsyncs 500
Innodb_os_log_pending_fsyncs 0
Innodb_os_log_pending_writes 0
Innodb_os_log_written 343552
Innodb_page_size 16384
Innodb_pages_created 4
Innodb_pages_read 2555
Innodb_pages_written 795
Innodb_row_lock_current_waits 0
Innodb_row_lock_time 0
Innodb_row_lock_time_avg 0
Innodb_row_lock_time_max 0
Innodb_row_lock_waits 0
Innodb_rows_deleted 0
Innodb_rows_inserted 352
Innodb_rows_read 818617
Innodb_rows_updated 88
------------------
命中率=innodb_buffer_pool_read_requests / (innodb_buffer_pool_read_requests + innodb_buffer_pool_read_ahead + innodb_buffer_pool_reads)
innodb_buffer_pool_size: 若是不使用InnoDB存儲引擎，能夠不用調整這個參數，若是須要使用，在內存容許的狀況下，儘量將全部的InnoDB數據文件存放如內存中，一樣將但來講也是「越大越好」
innodb_additional_pool_size
這個值不用分配太大，系統能夠自動調。不用設置過高。一般比較大數據設置16Ｍ夠用了，若是表比較多，能夠適當的增大。若是這個值自動增長，會在error log有中顯示的。20M足夠了。
innodb_log_file_size
做用：指定日誌的大小
分配原則：幾個日誌成員大小加起來差很少和你的innodb_buffer_pool_size相等。在高寫入負載尤爲是大數據集的狀況下很重要。這個值越大則性能相對越高，可是要注意到可能會增長恢復時間。
說明：這個值分配的大小和數據庫的寫入速度，事務大小，異常重啓後的恢復有很大的關係。
innodb_log_buffer_size：
做用：事務在內存中的緩衝。
分配原則：控制在2-8M.這個值不用太多的。他裏面的內存通常一秒鐘寫到磁盤一次。具體寫入方式和你的事務提交方式有關。通常最大指定爲3M比較合適。
參考：Innodb_os_log_written(show global status 能夠拿到)
若是這個值增加過快，能夠適當的增長innodb_log_buffer_size
另外若是你須要處理大理的text，或是blog字段，能夠考慮增長這個參數的值。
默認的設置在中等強度寫入負載以及較短事務的狀況下，服務器性能還能夠。若是存在更新操做峯值或者負載較大，就應該考慮加大它的值了。若是它的值設置過高了，可能會浪費內存 -- 它每秒都會刷新一次，所以無需設置超過1秒所需的內存空間。一般 8-16MB 就足夠了。越小的系統它的值越小。
innodb_flush_logs_at_trx_commit
做用：控制事務的提交方式
分配原則：這個參數只有3個值，0，1，2請確認一下自已能接受的級別。默認爲1，主庫請不要更改了。性能更高的能夠設置爲0或是2，但會丟失一秒鐘的事務。
值爲1時：innodb 的事務LOG在每次提交後寫入日誌文件，並對日誌作刷新到磁盤。這個能夠作到不丟任何一個事務。
值爲2事，也就是不把日誌刷新到磁盤上，而只刷新到操做系統的緩存上。日誌仍然會每秒刷新到磁盤中去，所以一般不會丟失每秒1-2次更新的消耗。若是設置爲 0 就快不少了，不過也相對不安全了 -- MySQL服務器崩潰時就會丟失一些事務。設置爲 2 只會丟失刷新到操做系統緩存的那部分事務。
innodb_file_per_table
做用：使每一個Innodb的表，有自已獨立的表空間。如刪除文件後能夠回收那部分空間。
分配原則：只有使用不使用。但DB還須要有一個公共的表空間。
InnoDB 默認會將全部的數據庫InnoDB引擎的表數據存儲在一個共享空間中：ibdata1，增刪數據庫的時候，ibdata1文件不會自動收縮，單個數據庫的備份也將成爲問題。一般只能將數據使用mysqldump 導出，而後再導入解決這個問題。
查看是否開啓：
mysql> show variables like ‘%per_table%’;
開啓
innodb_file_per_table=1
請適當的增長innodb_open_files
innodb_open_files
做用：限制Innodb能打開的表的數據。
分配原則：若是庫裏的表特別多的狀況，請增長這個。這個值默認是300。這個值必須超過你配置的innodb_data_file_path個數。
請適當的增長table_cache
innodb_flush_method
做用：Innodb和系統打交道的一個IO模型
分配原則：Windows不用設置。UNIX能夠設置：fdatasync (默認設置)，O_DIRECT，和O_DSYNC
O_DIRECT跳過了操做系統的文件系統Disk Cache，讓MySQL直接讀寫磁盤。 有數據代表，若是是大量隨機寫入操做，O_DIRECT會提高效率。可是順序寫入和讀取效率都會下降。
innodb_max_dirty_pages_pct
做用：控制Innodb的髒頁在緩衝中在那個百分比之下，值在範圍1-100,默認爲90.
O_DIRECT的flush_method更適合於操做系統內存有限的狀況下（能夠避免沒必要要的對交換空間的讀寫操做），不然，它會因爲禁用了os的緩衝下降對數據的讀寫操做的效能。
使用memlock能夠避免MySQL內存進入swap