對mysql的高併發優化配置的一些思考

對mysql的高併發優化配置的一些思考

mysql的高併發優化配置方案不少，可是適應你本身的就變得不多了，咱們對數據庫的優化，無非就是爲了應對mysql的高併發狀況罷了。隨着大數據的時代的到來和網絡用戶的增多，不少企業中，可能天天應對的數量達百萬，千萬，甚至上億的pv量，這樣的量已是超過普通配置的mysql所承受的量，因此應對日益增加的pv量，咱們須要對mysql作出相應的對策，進一步優化mysql，達到咱們所預期的效果，預防由於高併發所引發的mysql宕機，經過調試優化mysql，咱們即可以有效的應對這一些狀況。

 下面咱們來談談關於mysql的一些優化方案，方案僅僅的參考，可能每一個人的實際狀況多是有的不一樣，可是大致上能夠嘗試這樣的優化。

1、基於redis作mysql讀寫分離。

 對於基於redis的作緩存處理優化，也不是很複雜，對於運維人員來講，你只要安裝redis和調試一下就能夠了，關於redis如何調用mysql（好像是須要java寫個腳本），那是開發的事了。基於redis讀寫分離優化並非很好講，在這裏我先貼個圖，而後再講講。如圖1-1所示：

圖1-1 基於redis實現mysql讀寫分離

由上圖所示，咱們能夠發現其實redis調用就是那麼回事，首先它是由用戶發送請求信息（讀或者寫），然而在有redis的狀況下；根據圖的解析能夠有如下。

1.1、redis響應請求過程。

讀：讀的過程可能複雜一點，用戶會直接先讀取redis數據庫，而後把請求結果返回到client；若是用戶在redis沒有讀取到想要請求結果，他會直接逃過redis直接讀取到mysql，而後redis會把數據複製一份到本地。

寫：寫的過程稍微簡單一點了，用戶會直接向redis寫入，而後redis在緩存到mysql上。可能你會發現，整個過程都基本是redis在工做，mysql好像沒它的事了，對的，咱們就是要的是這種效果，任何請求都交給redis處理後，那你還怕mysql響應不過來了嗎。

1.2、redis配置優化

Redis配置，主要的是作持久化配置，主從複製，還有一些安全的配置，大概就是這樣，上圖我是有畫的，至於過程配置我就不寫了，咱們大概有個思路就行了。

1.3、mysql優化配置（主從複製）

Mysql作主從複製，怎麼麼說呢，主要是爲了安全，通常來講，在master有兩臺slave就能夠了，已經足夠應對不少的意外狀況了。作主從複製和備份，要注意得是，主從兩臺mysql配置同樣，對於備份的數據，不要放在mysql目錄下，要另起路徑，並給與mysql權限。配置可參考mysql主從複製配置

1.4、mysql監控系統

對於Mysql作監控，我的認爲是頗有必要的，首先咱們能夠在無人值守的狀況之下，咱們能夠對mysql的狀態進行監控；經過監控，咱們不但能夠對mysql的負載狀況進行告警，並且能夠對mysql自己性能的一些優化處理，因此我在應用對mysql的監控中，使用了zabbix對負載狀況作告警處理，並結合pmm-server對mysql系統的優化。對於pmm-sercer在這裏先貼個圖，如圖1.二、1.3所示

 

圖1.2 mysql資源數據圖

圖1.3 mysql資源數據圖

由以上圖能夠發現，咱們能夠大致的能夠看到mysql的資源配置狀況，根據數值咱們能夠適當的優化，並調整一些mysql的自身的參數，這就是pmm-sever的監控的好處了。

對於zabbix，我如今就是拿來作告警處理，在對mysql的監控中，zabbix自己自帶的模板和結合percona插件，基本實現對整個mysql的監控（配合可參考percona監控mysql數據），由於兩個結合基本比較全面的實現對mysql的監控了，如圖1.4所示，可看到模板所提供的監控項。

圖1.4 zabbix的mysql模板監控項

總結以上，咱們能夠發現，一個良好的mysql優化架構，須要作的包括redis作讀寫分離，mysql主從，監控系統完善等等。若是你還有跟好的方案，也記得分享一下；接下來，咱們是針對mysql自己性能的優化，×××能的容錯率，在基礎上進一步提高mysql的性能。

2.、mysql自身的優化

總的來講仍是自身因素影響的比較多，咱們能夠經過修改my.cnf配置文件來對mysql進行進一步的優化。咱們能夠經過修改mysql的參數使得mysql擁有更可靠的性能。下面是個人數據庫配置，本身經過百度谷歌，找不少配置選項的解析（配置適合mysql5.5以上的版本），而後總結。但願對你有幫助。（注意一下優化配置均在【mysqld】選項下配置，不要搞錯成【mysql】）

[mysqld]
back_log = 300
binlog_format = MIXED
character-set-server=utf8mb4
long_query_time = 1
log-bin=/databack/data_logbin/mysql_binlog
innodb_log_file_size=2G
innodb_log_buffer_size=4M
innodb_buffer_pool_size=4G
#innodb_file_per_table = ON
innodb_thread_concurrency=8
innodb_flush_logs_at_trx_commit=2
#innodb_additional_mem_pool_size=4M
join_buffer_size = 8M
key_buffer_size=256M
max_connections = 1000
max_allowed_packet = 4M
max_connect_errors = 10000
myisam_sort_buffer_size = 64M
port = 3306
query_cache_type=1
query_cache_size = 64M
read_buffer_size=4M
read_rnd_buffer_size=4M
server-id = 1
skip-external-locking
slow_query_log = 1 
#skip-name-resolve
#skip-networking
sort_buffer_size = 8M
socket = /tmp/mysql.sock
table_open_cache=1024
thread_cache_size = 64
thread_stack = 256K
tmp_table_size=64M
wait_timeout = 10

下面是對上面配置的解析：

back_log = 300：該參數的值表示在MySql的鏈接數據達到#max_connections 時，在它暫時中止響應新請求以前的短期內有300個請求能夠被存在堆棧中，即新來的請求將會被存在堆棧中，以等待某一鏈接釋放資源，該堆棧的數量即back_log，等 mysql處理完其餘請求以後會對其做出響應，若是等待鏈接的數量超過#back_log，將不被授予鏈接資源。你能夠合理的設置你的back_log，可是該值不要高於操做系統的限制的值。系統的默認值爲50。Linux系統通常設置小於512的整數。

binlog_format = MIXED：配置主從模式下，選取同步的模式，Mysql主從的複製能夠有三種複製類型，分別是:語句的複製STATEMEN,行的複製ROW和混合類型的複製MIXED，語句的複製顧名思義就是在主服務器上執行的SQL語句，在從服務器上執行一樣的語句，行的複製就是把改變的內容複製過去，而不是把命令在從服務器上執行一遍。默認採用基於語句的複製，一旦發現基於語句的沒法精確的複製時，就會採用基於行的複製,配置，複製類型能夠經過binlog_format =在配置文件上配置

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

long_query_time = 1：設置慢查詢響應的時間，記錄超過1秒的SQL執行語句。

log-bin=/databack/data_logbin/mysql_binlog ：設置二進制日誌的存放路徑，若是不設置系統會默認存放到mysql的目錄下，建議建立新的目錄來存放二進制日誌，且該目錄不要同數據庫同個目錄，存放目錄擁有者爲mysql。

innodb_log_file_size=2G ：在高寫入負載尤爲是大數據集的狀況下很重要。這個值越大則性能相對越高，跟據服務器大小而異。這是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_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_file_per_table = ON：在5.6中，該選項屬性默認值是ON，因爲對新建的表有影響，因此在以前的版本中你須要把它設置成ON。這項設置告知InnoDB是否須要將全部表的數據單獨放在一個.ibd文件，這樣作的好處是使得每一個表都有自已獨立的表空間。每一個表的數據和索引都會存在自已的表空間中。也實現單表在不一樣的數據庫中移動，且空間能夠回收。

innodb_thread_concurrency=8：指服務器邏輯線程數能夠設置成與系統同樣數量，參數可配置成邏輯CPU數量的兩倍。

系統CPU查看命令以下：

查看邏輯CPU個數：

#cat /proc/cpuinfo |grep "processor"|sort -u|wc –l

查看物理CPU個數：

# cat /proc/cpuinfo | grep "physical id" |sort -u|wc -l

              

查看每一個物理CPU內核個數：

# cat /proc/cpuinfo |  grep "cpu cores" |uniq

innodb_flush_logs_at_trx_commit=2：系統默認值是 1，可是這樣設置會使得提交更新事務都會刷新到磁盤中，會形成資源耗費。因此須要值設置爲 2，這樣就不用不把日誌刷新到磁盤上，而只刷新到操做系統的緩存上。但然啦也能夠設置爲0， 這樣設置是很快，但也形成了相對的不安全，會致使MySQL服務器崩潰時就會丟失一些事務。而設置爲 2 恰好尼補了。

#innodb_additional_mem_pool_size=4M：該參數默認爲1M適當調整該參數的大小以確保全部數據都能存放在內存中提升訪問效率的，主要用來存放Innodb的內部目錄，這個值不用分配太大，系統能夠自動調。在mysql5.6.3能夠忽略。

join_buffer_size = 8M：表示#聯合查詢操做所能使用的緩衝區大小。

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

max_connections = 1000：設置置MySQL的最大鏈接，按你實際狀況適當設置就好。若是你常常看到‘Too many connections'錯誤，是由於max_connections的值過低了，因此須要設置更高的連接數，若是max_connection值被設高以後的缺陷是當服務器運行超過設置閾值或更高的活動事務時會變的沒有響應。

max_allowed_packet = 4M：這個參數mysql消息緩衝區的大小，若是這個太小可能會影響到部分操做，默認是1M，通常設置成4-16M就能夠了。

max_connect_errors = 10000：表示若是有同一個主機訪問的參數值超出該參數值個數的中斷錯誤鏈接，則該主機將被禁止鏈接。如需對該主機進行解禁，執行：FLUSH HOST。

myisam_sort_buffer_size = 64M：這個參數默認是8M，表示MyISAM表發生變化時從新排序所需的緩衝，通常64M就已經足夠了。

port = 3306：表示使用3306來作mysql啓動端口

query_cache_type=1：表示控制緩存的類型，有三個參數可選（0、1、2）設置爲0，表示緩存沒有應用，也就至關於禁用了，設置爲1，表示緩存全部的結果，設置爲2表示只緩存在select語句中經過SQL_CACHE指定須要緩存的查詢。

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

read_buffer_size=4M：表示按順序查詢操做包括讀、查詢等操做所能使用的緩衝區大小，和sort_buffer_size同樣，該參數對應的分配內存也是每鏈接獨享，通常不建議太大，對於4G到16G內存的服務器2M-8M就能夠了。

read_rnd_buffer_size=4M：表示是MySQL的隨機讀緩衝區大小。當任意順序讀取行時將分配一個隨機讀取緩衝區，進行排序查詢時，便分配隨機緩衝做爲該操做的緩衝區大小，一樣的對於4G到16G內存的服務器2M-8M就能夠了。

server-id = 1：表示作主從同步所定義的serverid，做爲master的server_id必須必slave端的要小，越小表示優先級越高，可是在同個網段內的mysql服務，不容許設置一樣的sever_id。參數可設參考範圍（1-200）。

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

slow_query_log = 1：開啓慢查詢日誌，做用於慢查詢日誌,顧名思義,就是查詢慢的日誌。

skip-name-resolve：禁止MySQL對外部鏈接進行DNS解析，使用這一選項能夠消除MySQL進行DNS解析的時間。但須要注意，若是開啓該選項，則全部遠程主機鏈接受權都要使用IP地址方式，不然MySQL將沒法正常處理鏈接請求。

skip-networking：開啓該選項能夠完全關閉MySQL的TCP/IP鏈接方式，若是WEB服務器是以遠程鏈接的方式訪問MySQL數據庫服務器則不要開啓該選項，不然將沒法正常鏈接。

sort_buffer_size = 8M：表示查詢排序時所能使用的緩衝區大小。它直接與實時鏈接的個數 有關，實時鏈接的個數乘以sort_buffer_size的大小就是實際分配的總共排序緩衝區大小。因此，對於內存在4GB-8G左右的服務器能夠設置爲6-16M。

socket = /tmp/mysql.sock：mysql.sock 文件做用主要是server和client在同一臺服務器，當使用本地鏈接時，就會使用socket進行鏈接，該文件通常是放在/var/lib/mysql/mysql.sock下，也經常使用ln –s 在/tmp目錄下作軟鏈接。

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

3、總結

    預防Mysql病發的狀況，是每一個企業所要面對的事情，大數據的到來，更加使得mysql的性能要求更高，因此對mysql的優化升級，也是迫在眉睫。以上是本人總結，僅僅提供參考，但願能幫到你。