當我們被人雇來監(jiān)測MySQL性能時，人們希望我們能夠檢視一下MySQL配置然后給出一些提高建議。許多人在事后都非常驚訝，因為我們建議他們僅僅改動幾個設(shè)置，即使是這里有好幾百個配置項。這篇文章的目的在于給你一份非常重要的配置項清單。

我們曾在幾年前在博客里給出了這樣的建議，但是MySQL的世界變化實在太快了！

寫在開始前…

即使是經(jīng)驗老道的人也會犯錯，會引起很多麻煩。所以在盲目的運用這些推薦之前，請記住下面的內(nèi)容：

一次只改變一個設(shè)置！這是測試改變是否有益的唯一方法。大多數(shù)配置能在運行時使用SET GLOBAL改變。這是非常便捷的方法它能使你在出問題后快速撤銷變更。但是，要永久生效你需要在配置文件里做出改動。一個變更即使重啟了MySQL也沒起作用？請確定你使用了正確的配置文件。請確定你把配置放在了正確的區(qū)域內(nèi)(所有這篇文章提到的配置都屬于 [mysqld])服務器在改動一個配置后啟不來了：請確定你使用了正確的單位。例如，innodb_buffer_pool_size的單位是MB而max_connection是沒有單位的。不要在一個配置文件里出現(xiàn)重復的配置項。如果你想追蹤改動，請使用版本控制。不要用天真的計算方法，例如”現(xiàn)在我的服務器的內(nèi)存是之前的2倍，所以我得把所有數(shù)值都改成之前的2倍“。基本配置

你需要經(jīng)常察看以下3個配置項。不然，可能很快就會出問題。

innodb_buffer_pool_size：這是你安裝完InnoDB后第一個應該設(shè)置的選項。緩沖池是數(shù)據(jù)和索引緩存的地方：這個值越大越好，這能保證你在大多數(shù)的讀取操作時使用的是內(nèi)存而不是硬盤。典型的值是5-6GB(8GB內(nèi)存)，20-25GB(32GB內(nèi)存)，100-120GB(128GB內(nèi)存)。

innodb_log_file_size：這是redo日志的大小。 redo日志被用于確保寫操作快速而可靠并且在崩潰時恢復。一直到MySQL 5.1，它都難于調(diào)整，因為一方面你想讓它更大來提高性能，另一方面你想讓它更小來使得崩潰后更快恢復。幸運的是從MySQL 5.5之后，崩潰恢復的性能的到了很大提升，這樣你就可以同時擁有較高的寫入性能和崩潰恢復性能了。一直到MySQL 5.5，redo日志的總尺寸被限定在4GB(默認可以有2個log文件)。這在MySQL 5.6里被提高。

一開始就把innodb_log_file_size設(shè)置成512M(這樣有1GB的redo日志)會使你有充裕的寫操作空間。如果你知道你的應用程序需要頻繁的寫入數(shù)據(jù)并且你使用的時MySQL 5.6，你可以一開始就把它這是成4G。

max_connections：如果你經(jīng)常看到‘Too many connections’錯誤，是因為max_connections的值太低了。這非常常見因為應用程序沒有正確的關(guān)閉數(shù)據(jù)庫連接，你需要比默認的 151連接數(shù)更大的值。max_connection值被設(shè)高了(例如1000或更高)之后一個主要缺陷是當服務器運行1000個或更高的活動事務時會變 的沒有響應。在應用程序里使用連接池或者在MySQL里使用進程池有助于解決這一問題。

InnoDB配置

從MySQL 5.5版本開始，InnoDB就是默認的存儲引擎并且它比任何其他存儲引擎的使用都要多得多。那也是為什么它需要小心配置的原因。

innodb_file_per_table：這項設(shè)置告知InnoDB是否需要將所有表的數(shù)據(jù)和索引存放在共享表空間里（innodb_file_per_table = OFF） 或者為每張表的數(shù)據(jù)單獨放在一個.ibd文件（innodb_file_per_table = ON）。每張表一個文件允許你在drop、truncate或者rebuild表時回收磁盤空間。這對于一些高級特性也是有必要的，比如數(shù)據(jù)壓縮。但是它不會帶來任何性能收益。你不想讓每張表一個文件的主要場景是：有非常多的表（比如10k+）。

MySQL 5.6中，這個屬性默認值是ON，因此大部分情況下你什么都不需要做。對于之前的版本你必須在加載數(shù)據(jù)之前將這個屬性設(shè)置為ON，因為它只對新創(chuàng)建的表有影響。

innodb_flush_log_at_trx_commit：默認值為1，表示InnoDB完全支持 ACID特性。當你的主要關(guān)注點是數(shù)據(jù)安全的時候這個值是最合適的，比如在一個主節(jié)點上。但是對于磁盤（讀寫）速度較慢的系統(tǒng)，它會帶來很巨大的開銷，因為每次將改變flush到redo日志都需要額外的fsyncs。將它的值設(shè)置為2會導致不太可靠（unreliable）因為提交的事務僅僅每秒才 flush一次到redo日志，但對于一些場景是可以接受的，比如對于主節(jié)點的備份節(jié)點這個值是可以接受的。如果值為0速度就更快了，但在系統(tǒng)崩潰時可能 丟失一些數(shù)據(jù)：只適用于備份節(jié)點。

innodb_flush_method: 這項配置決定了數(shù)據(jù)和日志寫入硬盤的方式。一般來說，如果你有硬件RAID控制器，并且其獨立緩存采用write-back機制，并有著電池斷電保護，那 么應該設(shè)置配置為O_DIRECT；否則，大多數(shù)情況下應將其設(shè)為fdatasync（默認值）。sysbench是一個可以幫助你決定這個選項的好工 具。

innodb_log_buffer_size: 這項配置決定了為尚未執(zhí)行的事務分配的緩存。其默認值（1MB）一般來說已經(jīng)夠用了，但是如果你的事務中包含有二進制大對象或者大文本字段的話，這點緩存 很快就會被填滿并觸發(fā)額外的I/O操作。看看Innodb_log_waits狀態(tài)變量，如果它不是0，增加 innodb_log_buffer_size。

其他設(shè)置

query_cache_size：query cache（查詢緩存）是一個眾所周知的瓶頸，甚至在并發(fā)并不多的時候也是如此。 最佳選項是將其從一開始就停用，設(shè)置query_cache_size = 0（現(xiàn)在MySQL 5.6的默認值）并利用其他方法加速查詢：優(yōu)化索引、增加拷貝分散負載或者啟用額外的緩存（比如memcache或redis）。如果你已經(jīng)為你的應用啟 用了query cache并且還沒有發(fā)現(xiàn)任何問題，query cache可能對你有用。這是如果你想停用它，那就得小心了。

log_bin：如果你想讓數(shù)據(jù)庫服務器充當主節(jié)點的備份節(jié)點，那么開啟二進制日志是必須的。如果這么做了之 后，還別忘了設(shè)置server_id為一個唯一的值。就算只有一個服務器，如果你想做基于時間點的數(shù)據(jù)恢復，這（開啟二進制日志）也是很有用的：從你最近的備份中恢復（全量備份），并應用二進制日志中的修改（增量備份）。二進制日志一旦創(chuàng)建就將永久保存。所以如果你不想讓磁盤空間耗盡，你可以用PURGE BINARY LOGS來清除舊文件，或者設(shè)置expire_logs_days來指定過多少天日志將被自動清除。

記錄二進制日志不是沒有開銷的，所以如果你在一個非主節(jié)點的復制節(jié)點上不需要它的話，那么建議關(guān)閉這個選項。

skip_name_resolve：當客戶端連接數(shù)據(jù)庫服務器時，服務器會進行主機名解析，并且當DNS很慢時，建立連接也會很慢。因此建議在啟動服務器時關(guān)閉skip_name_resolve選項而不進行DNS查找。唯一的局限是之后GRANT語句中只能使用IP地址了，因此在添加這項設(shè)置到一個已有系統(tǒng)中必須格外小心。

總結(jié)

當然還有其他的設(shè)置可以起作用，取決于你的負載或硬件：在慢內(nèi)存和快磁盤、高并發(fā)和寫密集型負載情況下，你將需要特殊的調(diào)整。然而這里的目標是使得 你可以快速地獲得一個穩(wěn)健的MySQL配置，而不用花費太多時間在調(diào)整一些無關(guān)緊要的MySQL設(shè)置或讀文檔找出哪些設(shè)置對你來說很重要上。