Mysql配置優化

my.cnf路徑

找到mysql的my.cnf文件

命令：which mysqld

找到mysqld以後命令：/usr/sbin/mysqld --verbose --help |grep -A 1 'Default options'

my.cnf配置

back_log = 300

查看當前mysql默認back_log值：show variables like 'back_log';

該參數表示當MySQL的鏈接數達到max_connections時會將進來的請求短期存儲在堆棧中，以等待某一個鏈接釋放。堆棧中請求的最大數量就是back_log的值。若是等待鏈接的數量超過back_log，將不被授予鏈接資源。

注意：back_log值不能超過Linux系統的TCP/IP鏈接的偵聽隊列的大小，若超過則無效，查看當前系統的TCP/IP鏈接的偵聽隊列的大小命令：cat /proc/sys/net/ipv4/tcp_max_syn_backlog。目前系統爲2048。對於Linux系統推薦設置爲大於512的整數。修改系統內核參數，能夠編輯/etc/sysctl.conf去調整它。如：net.ipv4.tcp_max_syn_backlog = 2048，改完後執行sysctl -p 讓修改當即生效。

character-set-server=utf8mb4

utf-8編碼可能2個字節、3個字節、4個字節的字符，可是MySQL的utf8編碼只支持3字節的數據，而移動端的表情數據是4個字節的字符。若是直接往採用utf-8編碼的數據庫中插入表情數據，Java程序中將報SQL異常utf8mb4編碼是utf8編碼的超集，兼容utf8，而且能存儲4字節的表情字符。 採用utf8mb4編碼的好處是，存儲與獲取數據的時候，不用再考慮表情字符的編碼與解碼問題。

slow_query_log = ON
slow_query_log_file = /usr/local/mysql/data/slow.log
long_query_time = 1

slow_query_log 慢查詢開啓狀態
slow_query_log_file 慢查詢日誌存放的位置（這個目錄須要MySQL的運行賬號的可寫權限，通常設置爲MySQL的數據存放目錄）
long_query_time 查詢超過多少秒才記錄到慢查詢日誌裏面。

server-id=1
log-bin=/databack/data_logbin/mysql_binlog

server-id表示當前服務器Id，若是集羣方式該值不能重複。

log-bin表示二進制文件存放路徑。

innodb_log_file_size=2G

該參數決定着mysql事務日誌文件（ib_logfile0）的大小.

在高寫入負載尤爲是大數據集的狀況下很重要。這個值越大則性能相對越高，跟據服務器大小而異。這是redo日誌的大小。redo日誌被用於確保寫操做快速而可靠而且在崩潰時恢復。在MySQL 5.5，redo日誌的總尺寸被限定在4GB(默承認以有2個log文件)。而MySQL 5.6裏能夠設置容許大於4G。你能夠一開始就把它設置成4G。這個值的設置實際上是能夠計算的 你能夠經過命令SHOW GLOBAL STATUS的輸出看Innodb_os_log_written的值，把該值除以1024*1024 獲得的結果是每分鐘處理的redo日誌大小，而後再乘以60獲得每小時處理的日誌大小，由於在5.5以上版本都是默認有兩個日誌重作日誌文件ib_logfile0和ib_logfile1，所獲得結果再除以2，再取整就是你的redo該設置大小了。

當一個日誌文件寫滿後，innodb會自動切換到另一個日誌文件，並且會觸發數據庫的檢查點（Checkpoint），這會致使innodb緩存髒頁的小批量刷新，會明顯下降innodb的性能。因爲日誌切換更頻繁，也就直接致使更多的BUFFER FLUSH，因爲日誌切換的時候是不能BUFFER FLUSH的， BUFFER寫不下去，致使沒有多餘的buffer 寫redo， 那麼整個MYSQL就HANG住，還有一種狀況是若是有一個大的事務，把全部的日誌文件寫滿了，尚未寫完，這樣就會致使日誌不能切換（由於實例恢復還須要，不能被循環複寫）這樣mysql就hang住了。能夠根據文件修改時間來判斷日誌文件的旋轉頻率，旋轉頻率太頻繁，說明日誌文件過小了。

innodb_log_buffer_size=4M

該參數確保有足夠大的日誌緩衝區來保存髒數據在被寫入到日誌文件以前存儲在內存中。

默認爲1M，在默認的設置在中等強度寫入負載以及較短事務的狀況下，服務器性能還能夠。若是存在更新操做峯值或者負載較大，就應該考慮加大它的值了。在 InnoDB在事務提交前，並不將改變的日誌寫入到磁盤中，所以在大事務中，能夠減輕磁盤I/O的壓力。一般狀況下，若是不是寫入大量的超大二進制數據，4MB-8MB已經足夠了。

innodb_buffer_pool_size=4G

這配置對Innodb表來講很是重要。該參數主要做用是緩存innodb表的索引，數據，插入數據時的緩衝因爲Innodb把數據和索引都緩存起來，所以在配置該參數時，能夠設置它高達60-80% 的可用內存（官網是建議的也是系統內存的80%左右）。緩衝池是數據和索引緩存的地方這能保證你在大多數的讀取操做時使用的是內存而不是硬盤。通常配置的值是5-6GB(8GB內存)，19-25GB(32GB內存)，38-50GB(64GB內存)僅供參考。

innodb_flush_logs_at_trx_commit=2

innodb_flush_log_at_trx_commit設置爲1時，每次commit時都會將事務日誌刷到磁盤上，io操做頻繁性能低下，絕對安全不會丟失事務；innodb_flush_log_at_trx_commit設置爲0時，每次commit時都會將事務日誌寫入innodb log buffer ,而後每秒Log Thread 會將事務日誌從innodb log buffer刷新到ib_ogfile(也就刷新到了磁盤）。因此mysqld進程的崩潰時，innodb log buffer可能會有一秒的日誌沒有刷新出來，可是在這種狀況下，MySQL性能最好；

innodb_flush_log_at_trx_commit設置爲2時，每次commit時都會將事務日誌寫入到innodb log buffer同時也會寫入到os cache，而後每秒從os cache刷新到ib_logfile(也就是刷新到了磁盤）。只有在操做系統崩潰時纔會丟失事務。

join_buffer_size = 4M

只有當sql語句explain的結果type爲ALL,index,rang或者Index_merge的時候使用的buffer。實際上參與join的每個表都須要一個join buffer。須要注意的是，每個線程都會建立本身獨立的buffer而不是整個系統共享，因此設置的值過大會形成系統內存不足。

若是應用中，不多出現join語句，則能夠不用太在意join_buffer_size參數的設置大小。若是join語句不是不多的話，我的建議能夠適當增大join_buffer_size到1MB左右，若是內存充足能夠設置爲2MB。對於sort_buffer_size來講，通常設置爲2-4MB能夠知足大多數應用的需求。

當咱們使用explain來查詢sql語句的查詢計劃的時候，type（join type）字段是一個很重要的觀察對象。

ALL：對涉及到的表進行全表掃描，當表的數據量比較大的時候，全表掃描是比較費時費力的操做，這種狀況是咱們要避免出現的。

index：對涉及到的索引進行索引掃描，跟ALL相似，在數據量較大的時候也是費時費力的操做，也是須要避免出現的情形。

range：使用索引查詢必定範圍的數據，這是咱們能夠接受的操做。
到這裏能夠結合join_buffer_size的介紹進行部分總結：ALL、index這種操做是最壞狀況下的操做，即便使用了join_buffer_size，當數據量較大的狀況下也不會有很好的性能。range使用了索引，查詢部分數據，使用join_buffer_size是能夠提高性能的。因此咱們選擇調優join_buffer_size參數的緣由在因而否使用了不少join type爲range的join查詢。

key_buffer_size=256M

指定索引緩衝區的大小，它決定索引處理的速度，你能夠設置成系統的物理內存的1/4，它主要針對的是MyISAM引擎，可是設置大少不要超過4G，否則會出現問題。

max_connections = 1000

設置置MySQL的最大鏈接，按你實際狀況適當設置就好。若是你常常看到‘Too many connections'錯誤，是由於max_connections的值過低了。

max_allowed_packet = 4M

這個參數mysql消息緩衝區的大小，限制server接受的數據包大小。有時候大的插入和更新會被max_allowed_packet 參數限制掉，致使失敗。

max_connect_errors = 10000

表示若是有同一個主機訪問mysql超出該參數值個數的中斷錯誤鏈接，則該主機將被禁止鏈接。只針對鏈接錯誤，只計算協議握手錯誤，而且僅用於經過驗證的主機（HOST_VALIDATED = YES）。

myisam_sort_buffer_size = 64M

針對Myisam表設置在REPAIR TABLE，或者用 CREATE INDEX 建立索引或 ALTER TABLE 的過程當中排序索引所分配的緩衝區大小。可設置範圍4Bytes 至 4GB，默認爲8MB。Sort Buffer 是單個線程的，因此當多個線程同時進行排序的時候，系統中就會出現多個Sort Buffer。通常能夠經過增大 Sort Buffer 來提升 ORDER BY 或是 GROUP BY 的處理性能。

query_cache_type=1

表示查詢緩存的類型，有三個參數可選（0、一、2）設置爲0：表示沒有使用緩存，設置爲1：表示緩存全部的查詢，設置爲2：表示只緩存在select語句中經過SQL_CACHE指定須要緩存的查詢結果。查詢緩存會跟蹤查詢中涉及的每一個表，若是這寫表發生變化，那麼和這個表相關的全部緩存都將失效

能夠在 SELECT 語句中指定查詢緩存的選項，對於那些確定要實時的從表中獲取數據的查詢，或者對於那些一天只執行一次的查詢，咱們均可以指定不進行查詢緩存，使用 SQL_NO_CACHE 選項。
對於那些變化不頻繁的表，查詢操做很固定，咱們能夠將該查詢操做緩存起來，這樣每次執行的時候不實際訪問表和執行查詢，只是從緩存得到結果，能夠有效地改善查詢的性能，使用SQL_CACHE 選項。

query_cache_size = 64M

參數表示mysql查詢結果的緩衝區大小，通常不建議設置太大，由於設置太大會增長開銷，通常設置成32M-256M左右便可，設置參數通常爲2的倍數。

緩存存放在一個引用表中，經過一個哈希值引用，這個哈希值包括查詢自己，數據庫，客戶端協議的版本等，任何字符上的不一樣，例如空格，註釋都會致使緩存不命中。當查詢中有一些不肯定的數據時，是不會緩存的，比方說now(),current_date(),自定義函數，存儲函數，用戶變量，字查詢等。因此這樣的查詢也就不會命中緩存，可是還會去檢測緩存的，由於查詢緩存在解析SQL以前，因此MySQL並不知道查詢中是否包含該類函數，只是不緩存，天然不會命中。
對InnoDB表，當修改一個表時，設置了緩存失效，可是多版本特性會暫時將這修改對其餘事務屏蔽，在這個事務提交以前，全部查詢都沒法使用緩存，直到這個事務被提交，因此長時間的事務，會大大下降查詢緩存的命中 

read_buffer_size=4M

是MySQL讀入緩衝區大小。對錶進行順序掃描的請求將分配一個讀入緩衝區，MySQL會爲它分配一段內存緩衝區。read_buffer_size變量控制這一緩衝區的大小。若是對錶的順序掃描請求很是頻繁，而且你認爲頻繁掃描進行得太慢，能夠經過增長該變量值以及內存緩衝區大小提升其性能。

read_rnd_buffer_size=4M

由於sort後的數據是以key-value的形式存在的，使用這些行指針去讀取數據，將是以指針數據物理的順序去讀取，很大程度上是隨機的方式讀取數據的。MySQL從sort_buffer中讀取這些行指針數據，而後經過指針排序後存入read_rnd_buffer中，以後再經過指針讀取數據時，基本上都是順序讀取了。

read_rnd_buffer_size是很重要的參數，尤爲工做在以下場景：

     * sort_buffer中存的是行指針而不是要查詢的數據。

     * 查詢的字段中包含Blob/Text字段。

     * sort後有大量的數據行（limit 10並不能幫助你，由於MySQL是經過指針獲取行數據的）

若是你取出不多字段的數據（小於max_length_for_sort_data）,行數據將會所有存儲在sort buffer裏，所以將不須要read_rnd_buffer_size這個參數。而若是你查詢的字段數據很長（這些字段極可能含有Text/Blob字段），比max_length_for_sort_data還長，read_rnd_buffer_size這個參數將派上用場。

skip-external-locking

開啓該選項表示避免MySQL的外部鎖定，減小出錯概率加強穩定性，適用於單服務器環境。

sort_buffer_size = 8M

 是MySql執行排序使用的緩衝大小。若是想要增長ORDER BY的速度，首先看是否可讓MySQL使用索引而不是額外的排序階段。若是不能，能夠嘗試增長sort_buffer_size變量的大小。

table_open_cache=1024

table_cache主要用於設置table高速緩存的數量。因爲每一個客戶端鏈接都會至少訪問一個表，所以此參數的值與max_connections有關。你能夠經過命令show variables like '%open%'; 查看open_files_limit參數,大量使用MyISAM的環境裏，應該保證open_files_limit表類型至少是table_cache的二到三倍，調到512-1024最佳。

thread_cache_size = 64

這個變量值表示的是能夠從新利用保存在緩存中線程的數量,當斷開鏈接時若是緩存中還有空間,那麼客戶端的線程將被放到緩存中,若是線程從新被請求，那麼請求將從緩存中讀取,若是緩存中是空的或者是新的請求，那麼這個線程將被從新建立,若是有不少新的線程，增長這個值能夠改善系統性能.經過比較 Connections 和 Threads_created 狀態的變量，能夠看到這個變量的做用 根據物理內存設置規則能夠作如下配置2G-4G能夠設置爲16-64左右，固然大於4G的服務器，設置64也已經足夠了。

thread_stack = 256K

表示每一個鏈接線程被建立時，MySQL給它分配的內存大小，對於8-16G的服務器設置成256K就能夠了，再大一點的，能夠適當增長呢。

tmp_table_size=64M

表示定義一個臨時表的大小，該值默認爲16M，可調到64-256最佳，線程獨佔，太大可能內存不夠形成I/O堵塞，若是動態頁面能夠適當調大點。

wait_timeout = 10

表示指定一個請求的最大鏈接時間，該值過大會致使，MySQL裏大量的SLEEP進程沒法及時釋放，拖累系統性能，不過也不能把這個指設置的太小，不然你可能會遭遇到「MySQL has gone away」之類的問題。  系統默認是8個小時，感受太大，能夠設置小點。