MySQL必須調整的10項配置優化

即便是經驗老道的人也會犯錯，會引發不少麻煩。因此在盲目的運用這些推薦以前，請記住下面的內容：

一次只改變一個設置！這是測試改變是否有益的惟一方法。

大多數配置能在運行時使用SET GLOBAL改變。這是很是便捷的方法它能使你在出問題後快速撤銷變動。可是，要永久生效你須要在配置文件裏作出改動。

一個變動即便重啓了MySQL也沒起做用？請肯定你使用了正確的配置文件。請肯定你把配置放在了正確的區域內(全部這篇文章提到的配置都屬於 [mysqld])

服務器在改動一個配置後啓不來了：請肯定你使用了正確的單位。例如，innodb_buffer_pool_size的單位是MB而max_connection是沒有單位的。

不要在一個配置文件裏出現重複的配置項。若是你想追蹤改動，請使用版本控制。

不要用天真的計算方法，例如」如今個人服務器的內存是以前的2倍，因此我得把全部數值都改爲以前的2倍「。

基本配置

你須要常常察看如下3個配置項。否則，可能很快就會出問題。

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

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

一開始就把innodb_log_file_size設置成512M(這樣有1GB的redo日誌)會使你有充裕的寫操做空間。若是你知道你的應用程序須要頻繁的寫入數據而且你使用的時MySQL 5.6，你能夠一開始就把它這是成4G。

max_connections:
若是你常常看到‘Too many
connections’錯誤，是由於max_connections的值過低了。這很是常見由於應用程序沒有正確的關閉數據庫鏈接，你須要比默認的
151鏈接數更大的值。max_connection值被設高了(例如1000或更高)以後一個主要缺陷是當服務器運行1000個或更高的活動事務時會變
的沒有響應。在應用程序裏使用鏈接池或者在MySQL裏使用進程池有助於解決這一問題。
InnoDB配置

從MySQL 5.5版本開始，InnoDB就是默認的存儲引擎而且它比任何其餘存儲引擎的使用都要多得多。那也是爲何它須要當心配置的緣由。

innodb_file_per_table：
這項設置告知InnoDB是否須要將全部表的數據和索引存放在共享表空間裏（innodb_file_per_table = OFF）
或者爲每張表的數據單獨放在一個.ibd文件（innodb_file_per_table =
ON）。每張表一個文件容許你在drop、truncate或者rebuild表時回收磁盤空間。這對於一些高級特性也是有必要的，好比數據壓縮。可是它
不會帶來任何性能收益。你不想讓每張表一個文件的主要場景是：有很是多的表（好比10k+）。

MySQL 5.6中，這個屬性默認值是ON，所以大部分狀況下你什麼都不須要作。對於以前的版本你必需在加載數據以前將這個屬性設置爲ON，由於它只對新建立的表有影響。

innodb_flush_log_at_trx_commit：
默認值爲1，表示InnoDB徹底支持ACID特性。當你的主要關注點是數據安全的時候這個值是最合適的，好比在一個主節點上。可是對於磁盤（讀寫）速度
較慢的系統，它會帶來很巨大的開銷，由於每次將改變flush到redo日誌都須要額外的fsyncs。將它的值設置爲2會致使不太可靠
（reliable）由於提交的事務僅僅每秒才flush一次到redo日誌，但對於一些場景是能夠接受的，好比對於主節點的備份節點這個值是能夠接受
的。若是值爲0速度就更快了，但在系統崩潰時可能丟失一些數據：只適用於備份節點。

innodb_flush_method:
這項配置決定了數據和日誌寫入硬盤的方式。通常來講，若是你有硬件RAID控制器，而且其獨立緩存採用write-back機制，並有着電池斷電保護，那
麼應該設置配置爲O_DIRECT；不然，大多數狀況下應將其設爲fdatasync（默認值）。sysbench是一個能夠幫助你決定這個選項的好工
具。

innodb_log_buffer_size:
這項配置決定了爲還沒有執行的事務分配的緩存。其默認值（1MB）通常來講已經夠用了，可是若是你的事務中包含有二進制大對象或者大文本字段的話，這點緩存
很快就會被填滿並觸發額外的I/O操做。看看Innodb_log_waits狀態變量，若是它不是0，增長
innodb_log_buffer_size。
其餘設置

query_cache_size:
query cache（查詢緩存）是一個衆所周知的瓶頸，甚至在併發並很少的時候也是如此。
最佳選項是將其從一開始就停用，設置query_cache_size = 0（如今MySQL
5.6的默認值）並利用其餘方法加速查詢：優化索引、增長拷貝分散負載或者啓用額外的緩存（好比memcache或redis）。若是你已經爲你的應用啓
用了query cache而且尚未發現任何問題，query cache可能對你有用。這是若是你想停用它，那就得當心了。

log_bin：如
果你想讓數據庫服務器充當主節點的備份節點，那麼開啓二進制日誌是必須的。若是這麼作了以後，還別忘了設置server_id爲一個惟一的值。就算只有一
個服務器，若是你想作基於時間點的數據恢復，這（開啓二進制日誌）也是頗有用的：從你最近的備份中恢復（全量備份），並應用二進制日誌中的修改（增量備
份）。二進制日誌一旦建立就將永久保存。因此若是你不想讓磁盤空間耗盡，你能夠用 PURGE BINARY LOGS 來清除舊文件，或者設置 expire_logs_days 來指定過多少天日誌將被自動清除。

記錄二進制日誌不是沒有開銷的，因此若是你在一個非主節點的複製節點上不須要它的話，那麼建議關閉這個選項。

skip_name_resolve：當客戶端鏈接數據庫服務器時，服務器會進行主機名解析，而且當DNS很慢時，創建鏈接也會很慢。所以建議在啓動服務器時關閉skip_name_resolve選項而不進行DNS查找。惟一的侷限是以後GRANT語句中只能使用IP地址了，所以在添加這項設置到一個已有系統中必須格外當心。

總結

當 然還有其餘的設置能夠起做用，取決於你的負載或硬件：在慢內存和快磁盤、高併發和寫密集型負載狀況下，你將須要特殊的調整。然而這裏的目標是使得你能夠快 速地得到一個穩健的MySQL配置，而不用花費太多時間在調整一些可有可無的MySQL設置或讀文檔找出哪些設置對你來講很重要上。