經過查看mysql 配置參數、狀態來優化你的mysql

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