MySQL安裝後(hòu)需要調整什麼(me)?

面(miàn)對(duì)MySQL的DBA或者做MySQL性能(néng)相關的工作的人，我最喜歡問的問題是，在MySQL服務器安裝後(hòu)，需要調整什麼(me)，假設是以缺省的設置安裝的。

我很驚訝有非常多的人沒(méi)有合理的回答，很多的MySQL服務器都(dōu)在缺省的配置下運行。

盡管可以調整非常多的MySQL服務器變量，但是在通常情況下隻有少數的變量是真正重要的。在設置完這(zhè)些變量以後(hòu)，其他變量的改動通常隻能(néng)帶來相對(duì)有限的性能(néng)改善。

key_buffer_size ---- 非常重要，如果使用MyISAM表。如果隻使用MyISAM表，那麼(me)把它的值設置爲可用内存的30%到40%。恰當的大小依賴索引的數量、數據量和負載 ----記住MyISAM使用操作系統的cache去緩存數據，所以也需要爲它留出内存，而且數據通常比索引要大很多。然而需要查看是否所有的 key_buffer總是在被(bèi)使用 ---- key_buffer爲4G而.MYI文件隻有1G的情況并不罕見。這(zhè)樣(yàng)就有些浪費了。如果隻是使用很少的MyISAM表，希望它的值小一些，但是仍然至少要設成(chéng)16到32M，用于臨時表（占用硬盤的）的索引。

innodb_buffer_pool_size ---- 非常重要，如果使用Innodb表。相對(duì)于MyISAM表而言，Innodb表對(duì)buffer size的大小更敏感。在處理大的數據集（data set）時，使用缺省的key_buffer_size和innodb_buffer_pool_size，MyISAM可能(néng)正常工作，而Innodb可能(néng)就是慢得像爬一樣(yàng)了。同時Innodb buffer pool緩存了數據和索引頁，因此不需要爲操作系統的緩存留空間，在隻用Innodb的數據庫服務器上，可以設成(chéng)占内存的70%到80%。上面(miàn) key_buffer的規則也同樣(yàng)适用 ---- 如果隻有小的數據集，而且也不會戲劇性地增大，那麼(me)不要把innodb_buffer_pool_size設得過(guò)大。因爲可以更好(hǎo)地使用多餘的内存。

innodb_additional_pool_size ---- 這(zhè)個變量并不太影響性能(néng)，至少在有像樣(yàng)的（decent）内存分配的操作系統中是這(zhè)樣(yàng)。但是仍然需要至少設爲20MB（有時候更大），是Innodb分配出來用于處理一些雜事(shì)的。

innodb_log_file_size ---- 對(duì)于以寫操作爲主的負載(workload)非常重要，特别是數據集很大的時候。較大的值會提高性能(néng)，但增加恢複的時間。因此需要謹慎。我通常依據服務器的大小（server size）設置爲64M到512M。

innodb_log_buffer_size ---- 缺省值在中等數量的寫操作和短的事(shì)務的大多數負載情況下是夠用的。如果有大量的UPDATE或者大量地使用blob，可能(néng)需要增加它的值。不要把它的值設得過(guò)多，否則會浪費内存--log buffer至少每秒刷新一次，沒(méi)有必要使用超過(guò)一秒鍾所需要的内存。8MB到16MB通常是足夠的。小一些的安裝應該使用更小的值。

innodb_flush_logs_at_trx_commit ---- 爲Innodb比MyISAM慢100倍而哭泣？可能(néng)忘記了調整這(zhè)個值。缺省值是1，即每次事(shì)務提交時都(dōu)會把日志刷新到磁盤上，非常耗資源，特别是沒(méi)有電池備份的cache時。很多應用程序，特别是那些從MyISAM表移植過(guò)來的，應該把它設成(chéng)2。意味著(zhe)隻把日志刷新到操作系統的cache，而不刷新到磁盤。此時，日志仍然會每秒一次刷新到磁盤上，因此通常不會丢失超過(guò)1到2秒的更新。設成(chéng)0會更快一些，但安全性差一些，在MySQL服務崩潰的時候，會丢失事(shì)務。設成(chéng)2隻會在操作系統崩潰的時候丢失數據。

table_cache ---- 打開(kāi)表是昂貴的（耗資源）。例如，MyISAM表在MYI文件頭做标記以标明哪些表正在使用。您不會希望這(zhè)樣(yàng)的操作頻繁發(fā)生，通常最好(hǎo)調整cache 大小，使其能(néng)夠滿足大多數打開(kāi)的表的需要。它使用了一些操作系統的資源和内存，但是對(duì)于現代的硬件水平來說通常不是問題。對(duì)于一個使用幾百個表的應用， 1024是一個合适的值（注意每個連接需要各自的緩存）。如果有非常多的連接或者非常多的表，則需要增大它的值。我曾經(jīng)看到過(guò)使用超過(guò)100000的值。

thread_cache ---- 線程創建/銷毀是昂貴的，它在每次連接和斷開(kāi)連接時發(fā)生。我通常把這(zhè)個值至少設成(chéng)16。如果應用有時會有大量的并發(fā)連接，并且可以看到 threads_created變量迅速增長(cháng)，我就把它的值調高。目标是在通常的操作中不要有線程的創建。

query_cache ---- 如果應用是以讀爲主的，并且沒(méi)有應用級的緩存，那麼(me)它會有很大幫助。不要把它設得過(guò)大，因爲它的維護可能(néng)會導緻性能(néng)下降。通常會設置在32M到 512M之間。設置好(hǎo)後(hòu)，經(jīng)過(guò)一段時間要進(jìn)行檢查，看看是否合适。For certain workloads cache hit ratio is lower than would justify having it enabled.（這(zhè)句不會翻譯）

注意：就像看到的，上面(miàn)所說的都(dōu)是全局變量。這(zhè)些變量依賴硬件和存儲引擎的使用，而會話級的變量（per session variables）則與特定的訪問量(workload)相關。如果隻是一些簡單的查詢，就沒(méi)有必要增加sort_buffer_size，即使有 64G的内存讓您去浪費。而且這(zhè)樣(yàng)做還(hái)可能(néng)降低性能(néng)。我通常把調整會話級的變量放在第二步，在我分析了訪問量（或負載）之後(hòu)。此外在MySQL分發(fā)版中包含了一些my.cnf文件的例子，可以作爲非常好(hǎo)的模闆去使用。如果能(néng)夠恰當地從中選擇一個，通常會比缺省值要好(hǎo)。