安裝 MySQL 後，需要調整的 10 個性能配置項（參數優化）
注意：這篇博文的更新版本在這兒，MySQL 5.7 適用！
翻譯原文：http://www.cnblogs.com/glon/p/6484912.html
英文原文：https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/
在本文中，我們將探討在安裝好 MySQL 之後，可以進行調整的影響性能的前 10 個配置選項。
當我們作爲一名 MySQL 性能審計人員被錄用時，他們（公司）會希望我們重新檢查 MySQL 的配置文件，並且給出一些改進的建議。很多人感到很驚訝，因爲在大多數情況下，我們對已安裝的實例僅僅對少數的 MySQL 性能配置項建議進行調整，即使這個實例已經啓用了幾百個選項。本文的目的是給出一份列舉了一些關鍵性配置項的清單。
幾年前，我們曾經在這篇博文中給出了一些建議，但從那以後，MySQL 有了很大的改變。
寫在開始之前
即便是經驗豐富的人也會失誤，也引起很多麻煩。所以在盲目的應用本文推薦的配置項之前，請牢記下面的幾項：
- 一次只更改一個配置項！這是檢驗本次更改是否有利的途徑。
- 大多數配置項可以在運行時使用 SET GLOBAL 命令來修改。這種方式非常方便，並且如果修改後出現問題，還能馬上恢復原設置。但到最後，仍然需要把這個改變寫到配置文件中，使之永久生效。
- 一個配置的調整即使重啓了 MySQL 實例也沒有生效？那麼你是否使用了正確配置文件？你是否把這個選項寫到了正確的節下面？（本文的所有選項都歸屬於 [mysqld] 節）
- 服務器在配置調整之後啓動失敗：你是否使用了正確的單位？例如， innodb_buffer_pool_size 的單位是 byte，而 max_connection 是沒有單位的。
- 同一個配置文件裏不要出現重複的配置項。如果你想追蹤更改歷史，請使用版本控制器。
- 別做幼稚的運算，如“我的新服務器的 RAM 是舊的 2 倍，因此可以把所有的配置項的值都設置成之前的 2 倍”
基礎設置
你應該經常會查看或調整的 3 個 MySQL 性能配置項。如果沒有，你可能很快就會遇到問題。
-
innodb_buffer_pool_size：這是任何使用 InnoDB 存儲引擎的 MySQL 在安裝時第一個應該要查看的配置。Buffer pool 是用來緩存數據和索引的：儘可能地設置大一點，以確保在進行大多數讀操作時是讀內存而不是讀磁盤。一般設置值爲 5-6GB(8GB RAM)，20-25G(32GB RAM)，100-120GB(128GB RAM)。
- innodb_log_file_size：這個選項是設置 redo 日誌（重做日誌）的大小。redo 日誌 是用來確保寫入的數據能夠快速地寫入，並且持久化，還可以用於崩潰恢復(crash recovery)。MySQL 5.1 之前，這個選項很難去進行調整，因爲你既想要加大 redo 日誌來提高性能，又想要減小 redo 日誌來進行快速的崩潰恢復。幸運的是，自 MySQL 5.5 之後，崩潰恢復的性能有了很大的提高，現在你可以擁有快速寫入性能的同時，還能滿足快速崩潰恢復。一直到 MySQL 5.5，redo 日誌的總大小被限制在 4GB (默認有 2 個日誌文件)。這個在 MySQL 5.6 中被增加了。
啓動的時候設置 innodb_log_file_size = 512M（也就是 1GB 大小的 redo 日誌），這樣可以提供充足的寫空間。如果你知道你的應用是頻繁寫入的，並且你使用的 MySQL 版本是 MySQL 5.6，你可以設置 innodb_log_file_size = 4G。
- max_connections：如果你經常遇到 "Too many connections" 的錯誤，是因爲 max_connections 太小了。這個錯誤很長見到，因爲應用程序沒有正確地關閉與數據庫的連接，你需要設置連接數爲比默認 151 更大的值。max_connections 設置過高（如 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, 或者重建表的時候，會回收這個表空間。在一些高級特性，如壓縮的時候也需要開啓使用獨立表空間。然而這個選項卻不能帶來性能的提升。你不想使用獨立表空間的一個主要場景是：有很多的表（例如：10000 以上張表）。
在 MySQL 5.6 中，這個配置項是默認開啓的，因此多數情況下，你無需操作。對於早期的 MySQL 版本，需要在加載數據之前把它設置成 ON ，因爲它只對新創建的表有影響。
-
innodb_flush_log_at_trx_commit：默認值爲 1，表示 InnoDB 完全支持 ACID 特性。例如在在一個主節點上，你主要關注數據安全性，這是最好的設置值。然而它會對速度緩慢的磁盤系統造成很大的開銷，因爲每次將改變刷新到 redo 日誌的時候，都需要額外的 fsync 操作。設置爲 2，可靠性會差一點，因爲已提交的事務只會 1 秒鐘刷新一次到 redo 日誌，但在某些情況下，對一個主節點而言，這仍然是可以接受的，而且對於複製關係的從庫來說，這是一個很好的值。設置爲 0，速度更快，但是在遇到崩潰的時候很可能會丟失一些數據，這隻對從庫是一個好的設置值。
-
innodb_flush_method：這個設置項決定了數據和日誌刷新到磁盤的方式。當服務器硬件有 RAID 控制器、斷電保護、採取 write-back 緩存機制的時候，最常用的值是 O_DIRECT；其他大多數場景使用默認值 fdatasync。sysbench 是一個幫助你在這兩個值之間做出選擇好工具。
- innodb_log_buffer_size：這個設置項用來設置緩存還沒有提交的事務的緩衝區的大小。默認值(1MB) 一般是夠用的，但一旦事務之中帶有大 blob/text 字段，這個緩衝區會被很快填滿，並引起額外的 I/O 負載。看看 innodb_log_waits 這個狀態變量的值，如果不是 0 的話，需要增加 innodb_log_buffer_size。
其它設置
-
query_cache_size：Query Cache（查詢緩存）是一個衆所周知的瓶頸位，即使在併發量不高的時候也會出現。最好的選擇是從一開始就禁用它，通過設置 query_cache_size = 0 (MySQL 5.6 中現在已經默認禁用)，並通過其它途徑去提高讀查詢：合適的索引，增加從庫去分散讀壓力，或者使用一個額外的緩存（例如 memcache 或者 redis）。如果你的 MySQL 已經開啓了查詢緩存，並且沒有發現有任何錯誤，開啓查詢緩存可能是有利的，如果要禁用它，就需要謹慎了。
- log_bin：如果要讓一個節點做爲複製關係中的主節點，啓用二進制日誌（binary log）是必須的。這樣的話，同時需要設置全局唯一的 server_id。 對於單節點，在希望做基於時間點的恢復的時候，開啓這個選項也是很有用的：恢復最新的備份和應用二進制日誌。二進制日誌一旦創建，會被永久保存。所以如果不想耗盡磁盤空間，應該使用 PURGE BINARY LOGS 清理舊的二進制日誌文件，或者設置 expire_logs_days 選項指定多少天之後，自動清理過期的二進制日誌。
記錄二進制日誌不是沒有開銷的。所以，例如是一個複製關係中的從節點，建議禁用二進制日誌。
- skip_name_resolve：當一個客戶端連接上來的時候，服務端會執行主機名解釋操作，當 DNS 很慢時，建立的連接也會很慢。因此建議在啓動的時候設置 skip-name-resolve 來禁用 DNS 查找。唯一的侷限是 GRANT 語句僅且僅能使用 IP 地址，所以，在已有系統中添加這個選項時需要格外小心。
結論
當然，根據你的負載和硬件的實際情況，還有其他的設置能夠起到調優的作用：例如在小內存、高速磁盤，高併發，寫密集型的負載下，需要特定的調優。不過本文的目的是給出幾個 MySQL 的性能調優配置項，讓你可以快速得到一個穩健的配置文件，而不用花費大量的時間去調整一些沒那麼重要的 MySQL 配置項，或者去查閱官方文檔來找出哪些配置項對你而言是至關重要的。