要優化配置參數，首先要了解當前的配置參數以及運行情況。使用下列命令可以獲得目前服務器使用的配置參數：
1．獲取當前配置參數
要優化配置參數，首先要了解當前的配置參數以及運行情況。使用下列命令可以獲得目前服務器使用的配置參數：
mysqld –verbose –help
mysqladmin variables extended-status –u root –p
在MySQL控制檯裏面，運行下列命令可以獲取狀態變量的值：
mysql> SHOW STATUS;
如果只要檢查某幾個狀態變量，可以使用下列命令：
mysql> SHOW STATUS LIKE ‘[匹配模式]’; ( 可以使用%、?等 )
2．優化參數
參數優化基於一個前提，就是在我們的數據庫中通常都使用InnoDB表，而不使用MyISAM表。在優化MySQL時，有兩個配置參數是最重要的，即table_cache和key_buffer_size。
table_cache
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。
案例1：該案例來自一個不是特別繁忙的服務器
table_cache – 512
open_tables – 103
opened_tables – 1273
uptime – 4021421 (measured in seconds)
該案例中table_cache似乎設置得太高了。在峯值時間，打開表的數目比table_cache要少得多。
案例2：該案例來自一臺開發服務器。
table_cache – 64
open_tables – 64
opened-tables – 431
uptime – 1662790 (measured in seconds)
雖然open_tables已經等於table_cache，但是相對於服務器運行時間來說，opened_tables的值也非常低。因此，增加table_cache的值應該用處不大。
案例3：該案例來自一個upderperforming的服務器
table_cache – 64
open_tables – 64
opened_tables – 22423
uptime – 19538
該案例中table_cache設置得太低了。雖然運行時間不到6小時，open_tables達到了最大值，opened_tables的值也非常高。這樣就需要增加table_cache的值。
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得知詳情。
對於1G內存的機器，如果不使用MyISAM表，推薦值是16M（8-64M）。
案例1：健康狀況
key_buffer_size – 402649088 (384M)
key_read_requests – 597579931
key_reads – 56188
案例2：警報狀態
key_buffer_size – 16777216 (16M)
key_read_requests – 597579931
key_reads – 53832731
案例1中比例低於1:10000，是健康的情況；案例2中比例達到1:11，警報已經拉響。
優化query_cache_size
從4.0.1開始，MySQL提供了查詢緩衝機制。使用查詢緩衝，MySQL將SELECT語句和查詢結果存放在緩衝區中，今後對於同樣的SELECT語句（區分大小寫），將直接從緩衝區中讀取結果。根據MySQL用戶手冊，使用查詢緩衝最多可以達到238％的效率。
通過檢查狀態值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。
開啓二進制日誌( Binary Log )
二進制日誌包含所有更新數據的語句，其目的是在恢復數據庫時用它來把數據儘可能恢復到最後的狀態。另外，如果做同步複製( Replication )的話，也需要使用二進制日誌傳送修改情況。
開啓二進制日誌，需要設置參數log-bin。log_bin指定日誌文件，如果不提供文件名，MySQL將自己產生缺省文件名。MySQL會在文件名後面自動添加數字索引，每次啓動服務時，都會重新生成一個新的二進制文件。
此外，使用log-bin-index可以指定索引文件；使用binlog-do-db可以指定記錄的數據庫；使用binlog-ignore-db可以指定不記錄的數據庫。注意的是：binlog-do-db和binlog-ignore-db一次只指定一個數據庫，指定多個數據庫需要多個語句。而且，MySQL會將所有的數據庫名稱改成小寫，在指定數據庫時必須全部使用小寫名字，否則不會起作用。
在MySQL中使用SHOW MASTER STATUS命令可以查看目前的二進制日誌狀態。
開啓慢查詢日誌( slow query log )
慢查詢日誌對於跟蹤有問題的查詢非常有用。它記錄所有查過long_query_time的查詢，如果需要，還可以記錄不使用索引的記錄。下面是一個慢查詢日誌的例子：
開啓慢查詢日誌，需要設置參數log_slow_queries、long_query_times、log-queries-not-using-indexes。log_slow_queries指定日誌文件，如果不提供文件名，MySQL將自己產生缺省文件名。long_query_times指定慢查詢的閾值，缺省是10秒。log-queries-not-using-indexes是4.1.0以後引入的參數，它指示記錄不使用索引的查詢。
配置InnoDB
相對於MyISAM表來說，正確配置參數對於InnoDB表更加關鍵。其中，最重要的參數是innodb_data_file_path。它指定表數據和索引存儲的空間，可以是一個或者多個文件。最後一個數據文件必須是自動擴充的，也只有最後一個文件允許自動擴充。這樣，當空間用完後，自動擴充數據文件就會自動增長（以8MB爲單位）以容納額外的數據。例如：
innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:50M:autoextend
兩個數據文件放在不同的磁盤上。數據首先放在ibdata1中，當達到900M以後，數據就放在ibdata2中。一旦達到50MB，ibdata2將以8MB爲單位自動增長。
如果磁盤滿了，你需要在另外的磁盤上面增加一個數據文件。爲此，你需要查看最後一個文件的尺寸，然後計算最接近的整數（MB）。然後手工修改該文件的大小，並添加新的數據文件。例如：假設ibdata2已經有109MB數據，那麼可以修改如下：
innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:109M;/disk3/ibdata3:500M:autoextend
flush_time
如果系統有問題並且經常鎖死或重新引導，應將該變量設置爲非零值，這將導致服務器按flush_time 秒來刷新表的高速緩存。用這種方法來寫出對錶的修改將降低性能，但可減少表訛誤或數據丟失的機會。
3．存儲引擎
在MYSQL 3.23.0版本中，引入了MyISAM存儲引擎。它是一個非事務型的存儲引擎，成爲了MYSQL的缺省存儲引擎。但是，如果使用設置嚮導來設置參數，則它會把InnoDB作爲缺省的存儲引擎。InnoDB是一個事務型的存儲引擎。
創建表的時候，可以爲表指定存儲引擎，語法如下：
CREATE TABLE t (i INT) ENGINE = MyISAM
CREATE TABLE t (i INT) TYPE = MyISAM
如果沒有指定，則使用缺省的存儲引擎。也可以使用ALTER TABLE來更換表引擎，語法如下：
ALTER TABLE t ENGINE = MyISAM
同一數據庫中可以包含不同存儲引擎的表
事務型表具有以下特點：
Bulk_insert_buffer_size
該參數於4.0.3中引入。MyISAM使用一個樹型的緩衝區來加速大量的插入，如INSERT…SELECT，INSERT…VALUES(…),VALUES(…),…,LOAD DATA INFILE等。該參數指定了緩衝區的大小。缺省值爲8M，設置爲0則表示不使用該優化。
如果不使用MyISAM表，則可以將其設置爲0。
5．InnoDB存儲引擎
參考了很多資料，都沒有明確地表明如何優化InnoDB參數，以及如何監視這些參數設置是否合理，只有根據MySQL用戶手冊上面的介紹來進行設置。
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記錄日誌的方式。如果設置爲1，則每個事務提交的時候，MySQL都會將事務日誌寫入磁盤。如果設置爲0或者2，則大概每秒中將日誌寫入磁盤一次。（還不清楚0和2的區別）
實際測試發現，該值對插入數據的速度影響非常大，設置爲2時插入10000條記錄只需要2秒，設置爲0時只需要1秒，而設置爲1時則需要229秒。因此，MySQL手冊也建議儘量將插入操作合併成一個事務，這樣可以大幅提高速度。
根據MySQL手冊，在存在丟失最近部分事務的危險的前提下，可以把該值設爲0。
innodb_log_file_size
根據MySQL手冊，推薦值是innodb_buffer_pool_size的25%。
注意：在重新設置該值時，好像要把原來的文件刪除掉。
innodb_log_buffer_size
根據MySQL手冊，推薦值是8M。
innodb_additional_mem_pool_size
該參數指定InnoDB用來存儲數據字典和其他內部數據結構的內存池大小。缺省值是1M。通常不用太大，只要夠用就行，應該與表結構的複雜度有關係。如果不夠用，MySQL會在錯誤日誌中寫入一條警告信息。
根據MySQL手冊，對於2G內存的機器，推薦值是20M。
SHOW INNODB STATUS
顯示InnoDB存儲引擎的狀態
====================================================
aborted_clients 客戶端非法中斷連接次數
aborted_connects 連接mysql失敗次數
com_xxx xxx命令執行次數,有很多條
connections 連接mysql的數量
Created_tmp_disk_tables 在磁盤上創建的臨時表
Created_tmp_tables 在內存裏創建的臨時表
Created_tmp_files 臨時文件數
Key_read_requests The number of requests to read a key block from the cache
Key_reads The number of physical reads of a key block from disk
Max_used_connections 同時使用的連接數
Open_tables 開放的表
Open_files 開放的文件
Opened_tables 打開的表
Questions 提交到server的查詢數
Sort_merge_passes 如果這個值很大,應該增加my.cnf中的sort_buffer值
Uptime 服務器已經工作的秒數
提升性能的建議:
1.如果opened_tables太大,應該把my.cnf中的table_cache變大
2.如果Key_reads太大,則應該把my.cnf中key_buffer_size變大.可以用Key_reads/Key_read_requests計算出cache失敗率
3.如果Handler_read_rnd太大,則你寫的SQL語句裏很多查詢都是要掃描整個表,而沒有發揮鍵的作用
4.如果Threads_created太大,就要增加my.cnf中thread_cache_size的值.可以用Threads_created/Connections計算cache命中率
5.如果Created_tmp_disk_tables太大,就要增加my.cnf中tmp_table_size的值,用基於內存的臨時表代替基於磁盤的
Aborted_clients 由於客戶沒有正確關閉連接已經死掉，已經放棄的連接數量。
Aborted_connects 已經失敗的的MySQL服務器的連接的次數。
Connections 試圖連接MySQL服務器的次數。
Created_tmp_tables 當執行語句時，已經被創造了的隱含臨時表的數量。
Delayed_insert_threads 正在使用的延遲插入處理器執行的數量。
Delayed_writes 用INSERT DELAYED寫入的行數。
Delayed_errors 用INSERT DELAYED寫入的發生某些錯誤(可能重複鍵值)的行數。
Flush_commands 執行FLUSH命令的次數。
Handler_delete 請求從一張表中刪除行的次數。
Handler_read_first 請求讀入表中第一行的次數。
Handler_read_key 請求數字基於鍵讀行。
Handler_read_next 請求讀入基於一個鍵的一行的次數。
Handler_read_rnd 請求讀入基於一個固定位置的一行的次數。
Handler_update 請求更新表中一行的次數。
Handler_write 請求向表中插入一行的次數。
Key_blocks_used 用於關鍵字緩存的塊的數量。
Key_read_requests 請求從緩存讀入一個鍵值的次數。
Key_reads 從磁盤物理讀入一個鍵值的次數。
Key_write_requests 請求將一個字段寫入緩存次數。
Key_writes 將一個鍵值物理寫入磁盤的次數。
Max_used_connections 同時使用的連接的最大數目。
Not_flushed_key_blocks 在建緩存中已經改變但是還沒被清空到磁盤上的鍵值。
Not_flushed_delayed_rows 在INSERT DELAY隊列中等待寫入的行的數量。
Open_tables 打開表的數量。
Open_files 打開文件的數量。
Open_streams 打開流的數量(主要用於日誌記載）
Opened_tables 已經打開的表的數量。
Questions 發往服務器的查詢的數量。
Slow_queries 要花超過long_query_time時間的查詢數量。
Threads_connected 當前打開的連接的數量。
Threads_running 不在睡眠的執行數量。
Uptime 服務器工作了多少秒。
關於上面的一些註釋：
如果Opened_tables太大，那麼你的table_cache數可能太小。
如果key_reads太大，那麼你的key_cache可能太小。緩存命中率可以用key_reads/key_read_requests計算。
如果Handler_read_rnd太大，那麼你很可能有大量的查詢需要MySQL掃描整個表或你有沒正確使用鍵值的連接(join)。
轉載:http://www.i5good.com/2012011046.html