Mysql一些重要配置參數的學習與整理（二）

    原文地址：Mysql一些重要配置參數的學習與整理（二）

   上一篇，Mysql一些重要配置參數的學習與整理（一）中，咱們瞭解和學習了mysql配置中的一些重要參數，今天繼續進行學習，mysql的配置參數不少，不可能作到面面俱到，這裏的總結和整理只是針對於現實生產環境中用到的一些配置參數的學習，接下來，開始本篇的學習。

   innodb_flush_log_at_trx_commit = 2   

    這個變量的官方定義是：Controls the balance between strict ACID compliance for commit operations，and higher performance  that is possible when commit-related I/O operations are rearranged and done in batches。我本身的理解是用於控制兩種關係之間的平衡，這兩種關係：提交操做嚴格的ACID特性，提交相關的IO操做被分批的從新排列和完成時可能帶來的高性能。你能夠經過修改這個變量的默認值達到更好的性能，可是你可能會在乎外崩潰時丟失一秒的事務。

• 默認值爲 1 徹底符合數據庫ACID特性，這個值表示，在每次事務提交的時候，InnoDB日誌緩衝區的內容都會被寫入到日誌文件，而且日誌文件會被刷新到磁盤。

• 若是變量值爲0，則表示InnoDB日誌緩衝區的內容大約每秒被寫入日誌文件一次，而且日誌文件會被刷新到磁盤。那些日誌緩衝區中沒有寫入的內容會在事務提交的時候被寫入日誌文件。因爲進程調度的問題，每秒的刷新並不能100%保證每一秒都發生。因爲刷新磁盤的操做只有大約每秒才發生一次，因此在任何mysqld進程崩潰的時候，你都會喪失一秒的事務。
  

• 若是變量值爲2，則表示InnoDB日誌緩衝區的內容會在事務提交的時候寫入到日誌文件，而且日誌文件會大約每秒刷新一次磁盤。一樣的，因爲進程調度的問題，每秒的刷新並不能100%保證每一秒都發生。因爲刷新磁盤的操做只有大約每秒才發生一次，因此在操做系統崩潰或忽然斷電的時候，你都會喪失一秒的事務數據。

• 在MySQL 5.6.6版本中，InnoDB日誌刷新頻率由變量innodb_flush_log_at_timeout,控制，它容許你將日誌刷新頻率設置爲N秒（默認值是1，能夠設置1到2700之間的整數值），可是任何mysqld進程的崩潰都會清除高達N秒的事務數據。

• DDL變化和其餘內部InnoDB的活動，則是獨立的innodb_flush_log_at_trx_commit設置進行InnoDB日誌刷新。
  

• InnoDB的崩潰恢復機制是無論變量innodb_flush_log_at_trx_commit的設置的，事務要麼所有應用，要麼所有刪除。

    根據數據庫應用設置的持久性和一致性，建議參考以下方式進行InnoDB事務設置：

• 若是啓用了二進制日誌，設置sync_binlog=1。

• 老是設置innodb_flush_log_at_trx_commit=1。

    這麼建議的緣由是：許多操做系統和一些磁盤硬件愚弄刷新到磁盤的操做，他們可能會告訴mysqld：刷新操做已經發生，可是事實上並無發生。而後事務的持久性即便設置爲1，也不能獲得保證。在最糟糕的狀況忽然斷電甚至會形成InnoDB數據的損壞。在SCSI磁盤控制器或自己加速文件刷新的磁盤上使用電池支持的磁盤緩存，會使操做更安全。你也能夠嘗試使用Unix命令hdparm禁用磁盤寫入緩存的硬件高速緩存，或使用特定的硬件供應商提供的其餘一些命令。
    

    sync_binlog   

    若是這個變量的值大於0，MySQL服務器會在sync_binlog提交組被寫入到二進制日誌以後，使用fdatasync()命令同步二進制日誌到磁盤。默認的sync_binlog變量值爲0，表示不一樣步到磁盤。mysql服務器依賴於操做系統不時的刷新二進制文件的內容，用於任何其餘文件。值爲1是最安全的選擇，由於在崩潰的狀況下你最多從二進制日誌丟失一個提交組。然而，它也是最慢的選擇（除非你你的磁盤具備電池備份緩存，這會使得同步很是快）。

   innodb_lock_wait_timeout = 20   

    表示InnoDB事務從等待獲取行鎖到放棄的時間長度，默認的值爲50秒。一個事務試圖獲取被另外一個InnoDB事務鎖定的行所等待的最大時間，超時時會發出如下錯誤信息：
    ERROR 1205 (HY000)： Lock wait timeout exceeded； try restarting transaction（鎖等待超時，試圖重啓事務）

    當鎖等待超時後，當前的語句會回滾（並非整個事務回滾）。若是須要整個事務都回滾，須要在服務器啓動時經過innodb_rollback_on_timeout參數設置。

    在高度交互的應用程序或OTLP系統中，爲了更好的用戶反饋或將更新放入一個隊列等待後續處理，你可能會減少該變量值。對於長期運行的後端操做，好比在一個數據倉庫中存在大批量的插入或更新操做等待完成時，你可能會增長該值。

    innodb_lock_wait_timeout僅適用於InnoDB的行級鎖。一個MySQL表鎖不會發生在InnoDB，這個參數並不適用於等待表鎖。

    鎖等待超時值不適用於死鎖，由於在事務死鎖時，InnoDB會當即檢測到它們並事務回滾。

    innodb_lock_wait_timeout能夠在運行時，經過SET GLOBAL或SET SESSION聲明進行設置。修改全局的設置須要SUPER權限，並會影響接下來全部鏈接客戶端的操做。任何客戶端均可以在SESSION會話級別設置innodb_lock_wait_timeout，它只會影響到該客戶端。

    至此，線上mysql服務器上的配置文件參數已經所有作了整理，對於這些參數也有了必定的認識和了解，接下來，對於常用到的connections變量作一下整理，爲接下來與同事討論mysql的優化及設置作些準備，主要是如下幾個connections變量：
   max_connections    

    系統變量，它表示最大容許的併發客戶端鏈接數，會影響在服務器上運行的線程數量，默認值是151，增長該值會增長mysqld請求的文件描述符的數量。若是所請求的描述符的數量不可用，服務器會減小max_connections的值。鏈接拒絕是由於，max_connections的最大值，達到了Connection_errors_max_connections狀態變量的增量。
    上一篇，Mysql一些重要配置參數的學習與整理（一）中學習的 thread_cache_size 變量的默認值就與max_connections有關。

   max_user_connections    

    表示容許任何給定的MySQL用戶賬戶同時鏈接的最大數目。默認值爲0表示不限制。此變量能夠在服務器啓動時或運行時設置一個全局值。它也有一個只讀會話值，表示與當前會話相關聯的賬戶的有效同時鏈接的限制值。會話級別的max_user_connections初始化以下：

• 若是用戶賬戶具備非零的MAX_USER_CONNECTIONS資源限制（賬戶的資源限制經過GRANT語句指定），會話級別的MAX_USER_CONNECTIONS值就設爲該限制。

• 不然的話，會話級別的MAX_USER_CONNECTIONS的值會被設置爲全局值。

   Connection_errors_max_connections   

    表示當服務器中鏈接數達到max_connections的限制後，鏈接數被拒絕的數量。

     Connections                  

     表示嘗試鏈接到mysql服務器的數量，不管成功或失敗。

     Max_used_connections     

    從服務器啓動開始，已同時被使用的最大鏈接數。