Mysql參數配置優化說明

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：該案例來自一個性能不佳的服務器
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、一、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 秒來刷新表的高速緩存。用這種方法來寫出對錶的修改將下降性能，但可減小表訛誤或數據丟失的機會。
通常使用缺省值。

Binlog_cache_size
The size of the cache to hold the SQL statements for the binary log during a transaction. A binary log cache is allocated for each client if the server supports any transactional storage engines and if the server has binary log enabled(–log-bin option). If you often use big, multiple-statement transactions, you can increase this to get more performance. The Binlog_cache_use and Binlog_cache_disk_use status variables can be useful for tuning the size of this variable.

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

同一數據庫中能夠包含不一樣存儲引擎的表。

事務型表具備如下特色：
Ø Safer. Even if MySQL crashes or you get hardware problems, you can get your data back, either by automatic recovery or from a backup plus the transaction log.
Ø You can combine many statements and accept them all at the same time with the COMMIT statement (if autocommit is disabled).
Ø You can execute ROLLBACK to ignore your changes (if autocommit is disabled).
Ø If an update fails, all your changes will be restored. (With non-transaction-safe tables, all changes that have taken place are permanent.)
Ø Transaction-safe storage engines can provide better concurrency for tables that get many updates concurrently with reads.

非事務型表具備如下優勢：
Ø Much faster
Ø Lower disk space requirements
Ø Less memory required to perform updates

4．MyISAM存儲引擎

下面MyISAM的參數是MySQL手冊推薦的參數，聽說適應於大部分狀況。對於如何監視參數設置是否合理，仍然沒有頭緒。
max_connections=200
read_buffer_size=1M
read_rnd_buffer_size＝8M
sort_buffer_size=1M
Read_buffer_size

Each thread that does a sequential scan allocates a buffer of this size for each table it scans. If you do many sequential scans, you might want to increse this value.

Read_rnd_buffer_size
When reading rows in sorted order after a sort, the rows are read through this buffer to avoid disk seeks. Setting the variable to a large value can improve ORDER BY performance by a lot. However, this is a buffer allocated for each client, so you should not set the global variable to a large value. Instead, change the session variable only from within those clients that need to run large queries.

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
The size of each log file in a log group. The default is 5MB. The larger the value, the less checkpoint flush activity is needed in the buffer pool, saving disk I/O. But large log files also mean that recovery will be slower in case of a crash.

根據MySQL手冊，推薦值是innodb_buffer_pool_size的25%。

注意：在從新設置該值時，好像要把原來的文件刪除掉。

innodb_log_buffer_size
The size of the buffer that InnoDB uses to write to the log files on disk. Sensible values range from 1MB to 8MB. The default is 1MB. A large log buffer allows large transactions to run without a need to write the log to disk before the transactions commit. Thus, if you have big transactions, making the log buffer larger will save disk I/O.
根據MySQL手冊，推薦值是8M。

innodb_additional_mem_pool_size
該參數指定InnoDB用來存儲數據字典和其餘內部數據結構的內存池大小。缺省值是1M。一般不用太大，只要夠用就行，應該與表結構的複雜度有關係。若是不夠用，MySQL會在錯誤日誌中寫入一條警告信息。
根據MySQL手冊，對於2G內存的機器，推薦值是20M。

SHOW INNODB STATUS 顯示InnoDB存儲引擎的狀態