安裝MySQL後，須要調整的10個性能配置項

本文翻譯自 Percona 官方博客，適用於 MySQL 5.6 及 5.7 版本。
做者：Stephane Combaudon
原文：
https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/

在本博客中，咱們將和你們討論下 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 日誌），這樣能夠提供充足的寫空間。若是你知道你的應用是頻繁寫入的，還能夠再增大些。

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, 或者重建表的時候，會回收這個表空間。在一些高級特性，如壓縮的時候也須要開啓使用獨立表空間。然而這個選項卻不能帶來性能的提高。

在 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_size = 0)  ，該選項在 MySQL 5.6 後是默認禁用的，咱們能夠經過其餘途徑來提升查詢速度: 設計好的索引，增加讀寫分離，或者使用額外的緩存 (memcache or redis for instance)。若是您的 MySQL 已經啓用了查詢緩存而且從沒有發現過問題， 那麼查詢緩存多是對你有益的，這個時候若是你想禁用它的時候應該當心操做。

log_bin：

若是要讓一個節點作爲複製關係中的主節點，啓用二進制日誌（binary log）是必須的。同時須要設置全局惟一的 server_id。 若是是單實例數據庫，若是你要將數據恢復到以前時間點（使用最新的備份restore，而後使用binlog進行recover），那麼就須要二進制日誌。二進制日誌一旦建立，會被永久保存，因此若是不想耗盡磁盤空間，應該使用 PURGE BINARY LOGS 清理舊的二進制日誌文件，或者設置 expire_logs_days 選項指定多少天以後，自動清理過時的二進制日誌。

二進制文件記錄是須要消耗資源的，所以在主從複製環境中，若是備庫不須要 Binlog ，就能夠禁用掉。

skip_name_resolve：

當一個客戶端鏈接上來的時候，服務端會執行主機名解釋操做，當 DNS 很慢時，創建的鏈接也會很慢。所以建議在啓動的時候設置 skip-name-resolve 來禁用 DNS 查找。惟一的侷限是 GRANT 語句僅且僅能使用 IP 地址，因此，在已有系統中添加這個選項時須要格外當心。

結論

固然，根據你的負載和硬件的實際狀況，還有其餘的設置可以起到調優的做用：例如在小內存、高速磁盤，高併發，寫密集型的負載下，須要特定的調優。不過本文的目的是給出幾個 MySQL 的性能調優配置項，讓你快速配置一個合理的 MySQL 配置文件，而且瞭解哪些參數對你很重要，而不須要花費大量時候去閱讀官方文檔。