MySQL 參數筆記：參數彙總(持續更新)

一、前言

• 至 5.7.28 版本 MySQL 已經有 517 個參數，有關於元數據、性能、安全等等，那麼在配置 MySQL 或者優化的時候就需要了解一些參數的作用再根據業務，配置安全、穩定的 MySQL 實例。這篇博客會收集比較常用的參數進行彙總。

二、MySQL “雙一” 安全參數

• innodb_flush_log_at_trx_commit：MySQL 中 “雙一” 參數之一，控制 redo 日誌的刷盤機制，redo 日誌主要作用是來實現事務的持久化存儲和 innodb 自動故障恢復，設置不同的參數都可能會對性能和數據安全有影響。

  -- MySQL 默認爲 1
  show variables like 'innodb_flush_log_at_trx_commit';
  

  Variable_name	Value
  innodb_flush_log_at_trx_commit	1

  Redo Log：刷寫過程 log_buff —mysql寫 (write)—> log_file —OS刷新 (flush)—> 磁盤

  ---

  1. innodb_flush_log_at_trx_commit = 0：事務提交時，MySQL不會處理日誌緩存區的內容，也不會處理日誌文件的刷盤操作，由 MySQL 後臺 Master 線程每隔 1 秒將緩存區的數據刷寫到redo 日誌文件中。延時 1 秒鐘寫 意味着有丟失最近 1 秒的事務風險。
  2. innodb_flush_log_at_trx_commit = 1：事務提交時，會將日誌寫入文件中，同時會刷新到磁盤中，保證數據庫事務完全不會丟失。實時寫，實時刷 這種設置會影響數據庫的性能。
  3. innodb_flush_log_at_trx_commit = 2：事務提交時，會將日誌緩存區日誌寫入到文件中，但是不會刷新到磁盤中，而是取決於操作系統的調度。實時寫，延遲刷 如果數據庫宕機不會出現數據丟失，因爲事務已經刷新到 OS cache 操作系統每隔 1 秒會自動刷盤。但是如果系統也出現問題事務沒有刷新到磁盤中，那麼也會丟失最近 1 秒內的事務數據。

  ---

  從數據庫安全角度考慮總結如下：

  Variable_num	數據庫宕機	OS宕機
  innodb_flush_log_at_trx_commit = 0	丟失 1s 的數據	丟失 1s 的數據
  innodb_flush_log_at_trx_commit = 1	不會丟失數據	不會丟失數據
  innodb_flush_log_at_trx_commit = 2	不會丟失數據	丟失 1s 的數據

• sync_binlog：MySQL 中 “雙一” 參數之一，控制 binlog 的刷寫策略。binlog 主要應用於主從複製和配合備份工具恢復數據。binlog 安全也會影響到主從的安全。

  -- MySQL 中默認爲 1
  show variables like 'sync_binlog';
  

  Variable_name	Value
  sync_binlog	1

  主從複製：很少有 MySQL 單例支撐業務的情況，大部分 MySQL 應用都是採用集羣的方案，進行數據庫層面的讀寫分離，負載均恆或數據備份。而 MySQL 集羣本質可以分爲兩類，一類是依賴 MySQL Replication 的傳統集羣，另一類是依賴插件(MHA、Galera)真正集羣化解決方案 sync_binlog 維護傳統主從複製數據安全。

  ---

  1. sync_binlog = 0：事務提交時，將 binlog 信息寫入 binlog 文件中(OS Cache) 中，但 MySQL 不控制 Binlog 的刷盤操作，由文件系統自己控制緩存刷盤，這是有一定風險的，如果操作系統宕機，那麼 Belog cache 中的 Binlog 數據都會丟失。
  2. sync_binlog = 1：每一個事務提交時，MySQL 都會將 Binlog 刷寫到磁盤中，這樣，數據庫的安全性最高，但是性能損耗是最大的。
  3. sync_binlog = N N>1：表示 N 次提交後，MySQL 會調用文件系統刷盤操作，將 binlog 緩存刷新到磁盤中。如果宕機可能會丟失一部分數據。

  ---

三、MySQL 系統參數

• innodb_buffer_size：InnoDB 引擎最重要的緩存區 buffer_pool 用來存儲 InnoDB 索引頁面和數據，Undo 頁及其它一些輔助數據。它的大小是影響性能的重要因素，官方建議設置爲物理內存的 50% ～ 75%。

  -- innodb 引擎最大的內存區域 buffer pool 默認 128 MB
  show variables like 'innodb_buffer_pool_size';
  

  Variable_name	Value
  innodb_buffer_pool_size	134217728

• innodb_buffer_pool_instances：通過這個參數，把原來一整塊 Buffer pool 分割成多塊內存空間，每個空間管自己的空閒鏈表、LRU、刷新鏈表和其它數據結構。這大大增加了併發性，能夠有效利用緩存。默認值在 MySQL 5.6.6 取決於 buffer_pool_size 設置大小。

  -- 默認爲 1 MySQL 5.6.6 取決於 innodb_buffer_pool_size 的大小
  show variables like 'innodb_buffer_pool_instances';
  

  Variable_name	Value
  innodb_buffer_pool_instances	1

• innodb_log_file_size 和 innodb_log_files_in_group：兩個參數共同使用，決定 Redo 物理存儲空間的大小。Redo 空間越大可以存儲的增量日誌也就越大，可以有效降低 Buffer Pool 髒頁被淘汰的速度，同時減少 checkpoint 的次數，降低磁盤 IO 的置換率，從而提升數據庫的寫入效率。Redo 物理空間是 ib_logfile0 和 ib_logfile1 默認兩個文件置換使用，可以通過第二個參數進行調整。

  -- Redo 日誌物理存儲空間大小
  show variables like 'innodb_log_file_size';
  

  Variable_name	Value
  innodb_log_file_size	50331648

  -- 默認爲 兩個文件置換使用
  show variables like 'innodb_log_files_in_group';
  

  Variable_name	Value
  innodb_log_files_in_group	2

四、性能優化

• Max_connections：MySQL 的最大連接數，如果服務器的併發請求量比較大，可以調高這個值，當然這是要建立在機器能夠支撐的情況下，因爲如果連接數越來越多，MySQL 會爲每個連接提供緩衝區，就會開銷的越多的內存，所以需要適當的調整該值，不能隨便去提高設值。

  -- 查看 MySQL 最大連接數
  show variables like 'max_connections';
  -- 配置修改方式
  vim /etc/my.cnf 
  Max_connections=1024
  

  Variable_name	Value
  max_connections	151

  設置技巧：可以先打開數據庫設置一個比較大的測試值，使用 Max_used_connections 參數觀察如果 Max_used_connections 與 max_connections 相同則是因爲設置過少或者超出服務負載極限。

  -- 查看當前連接數 與 show processlist 相似
  show status like 'Max_used_connections';
  

  Variable_name	Value
  Max_used_connections	10

• back_log：MySQL 能暫存的連接數量，當 MySQL 線程在一個很短時間內得到非常多的連接請求時候它就會起作用，如果 MySQL 的連接數據達到 max_connections時候，新來的請求將會被存在堆棧中，等待某一連接釋放資源，該推棧的存儲數量既 back_log，如果等待連接的數量超過 back_log，將不被授予連接資源。

  -- back_log
  show variables like 'back_log';
  -- 配置文件修改
  vim /etc/my.cnf 
  back_log=1024
  

  Variable_name	Value
  back_log	80

  設置技巧：與 max_connections 設置方法相同測試業務查看連接數，通過設置反饋來決定 back_log 是否修改。