Mysql 優化

咱們究竟應該如何對MySQL數據庫進行優化？下面我就從MySQL對硬件的選擇、MySQL的安裝、my.cnf的優化、MySQL如何進行架構設計及數據切分等方面來講明這個問題。

服務器物理硬件的優化

在挑選硬件服務器時，咱們應該從下面幾個方面着重對MySQL服務器的硬件配置進行優化，也就是說將項目中的資金着重投入到以下幾處：

一、磁盤尋道能力（磁盤I/O），咱們如今用的都是SAS15000轉的硬盤，用6快這樣的硬盤做RAID1+0。MySQL每一秒鐘都在進行大量、複雜的查詢操做，對磁盤的讀寫量可想而知，因此，一般認爲磁盤I/O是約制MySQL性能的最大因素之一。對於日均訪問量在100萬PV以上的論壇（Discuz）、博客（Wordpress），若是性能很差，形成的直接後果就是MySQL的性能會很是低下！解決這一制約因素能夠考慮解決訪問是：使用RAID1+0磁盤陣列，注意不要嘗試RAID5，MySQL在PAID5磁盤陣列上的效率不會像你期待的那樣快，若是資金容許，能夠選擇固態硬盤SSD來替代SAS硬盤作RAID1+0。

二、CPU對於MySQL的影響也是不容忽視的，建議選擇運算能力強悍的CPU。推薦使用DELL R710（雙四核），商家的賣點也是其強大的虛擬化和數據庫能力。

三、對於一臺使用MySQL的DatabaseServer來講，建議服務器的內存不要小於2GB，推薦使用4GB以上的物理內存，不過內存對於如今的服務器而言能夠說是一個能夠忽略的問題，若是是高端服務器，基本上內存都超過了32GB，咱們的數據流服務器都是32GB內存。

我在工做中用的比較多的數據庫服務器是DELL R710/R720，其穩定性和性能都不錯，同時我也發現許多同行都是採用它做爲數據庫的服務器，因此在這裏也向你們推薦一下。

MySQL應採用編譯方式安裝

關於MySQL數據庫的線上環境安裝，我建議採起編譯安裝的方式，這樣性能會有較大的提高。服務器系統則建議CentOS6.7 X86_64，源碼包的編譯參數會默認以Debug模式生成二進制代碼，而Debug模式給MySQL帶來的性能損失是比較大的，因此當咱們編譯準備安裝的產品代碼時，必定不要忘記使用--without-debug參數禁止Debug模式。若是把--with-mysqld-ldflags和--with-client-ld-flags兩個編譯參數設置爲--all-static的話，能夠告訴編譯器以靜態的方式編譯，編譯結果將獲得最高的性能。使用靜態編譯和使用動態編譯的代碼相比，性能差距可能會達到5%至10%之多。在後面我會跟你們分享咱們線上MySQL數據庫的編譯參數，你們能夠參考下，而後根據本身的線上環境自行修改內容。

MySQL配置文件優化

[client]

port   =3306  #客戶端端口號爲3306

socket =/data/3306/mysql.sock #

default-character-set =utf8  #客戶端字符集,(控制character_set_client、character_set_connection、character_set_results)

 

[mysql]

no-auto-rehash  #僅僅容許使用鍵值的updates和deletes

 

[mysqld]  #組包括了mysqld服務啓動的參數，它涉及的方面不少，其中有MySQL的目錄和文件，通訊、網絡、信息安全，內存管理、優化、查詢緩存區，還有MySQL日誌設置等。

user    =mysql  #mysql_safe腳本使用MySQL運行用戶(編譯時--user=mysql指定),推薦使用mysql用戶。

port    =3306  #MySQL服務運行時的端口號。建議更改默認端口,默認容易遭受***。

socket =/data/3306/mysql.sock  #socket文件是在Linux/Unix環境下特有的，用戶在Linux/Unix環境下客戶端鏈接能夠不經過TCP/IP網絡而直接使用unix socket鏈接MySQL。

basedir =/application/mysql  #mysql程序所存放路徑,經常使用於存放mysql啓動、配置文件、日誌等

datadir =/data/3306/data  #MySQL數據存放文件(極其重要)

character-set-server =utf8  #數據庫和數據庫表的默認字符集。(推薦utf8,以避免致使亂碼)

log-error=/data/3306/mysql_xuliangwei.err  #mysql錯誤日誌存放路徑及名稱(啓動出現錯誤必定要看錯誤日誌,百分之百都能經過錯誤日誌排插解決。)

pid-file=/data/3306/mysql_xuliangwei.pid  #MySQL_pid文件記錄的是當前mysqld進程的pid，pid亦即ProcessID。

skip-locking  #避免MySQL的外部鎖定，減小出錯概率，加強穩定性。

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

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

open_files_limit   = 1024  #MySQLd能打開文件的最大個數,若是出現too mant openfiles之類的就須要調整該值了。

back_log = 384  #back_log參數是值指出在MySQL暫時中止響應新請求以前，短期內的多少個請求能夠被存在堆棧中。若是系統在短期內有不少鏈接，則須要增長該參數的值，該參數值指定到來的TCP/IP鏈接的監聽隊列的大小。不一樣的操做系統在這個隊列的大小上有本身的限制。若是試圖將back_log設置得高於操做系統的限制將是無效的，其默認值爲50.對於Linux系統而言，推薦設置爲小於512的整數。

max_connections = 800 #指定MySQL容許的最大鏈接進程數。若是在訪問博客時常常出現 Too Many Connections的錯誤提示，則須要增大該參數值。

max_connect_errors = 6000  #設置每一個主機的鏈接請求異常中斷的最大次數，當超過該次數，MySQL服務器將禁止host的鏈接請求，直到MySQL服務器重啓或經過flush hosts命令清空此host的相關信息。

wait_timeout = 120  #指定一個請求的最大鏈接時間，對於4GB左右內存的服務器來講，能夠將其設置爲5~10。

table_cache = 614K  #table_cache指示表高速緩衝區的大小。當MySQL訪問一個表時，若是在MySQL緩衝區還有空間，那麼這個表就被打開並放入表緩衝區，這樣作的好處是能夠更快速地訪問表中的內容。通常來講，能夠查看數據庫運行峯值時間的狀態值Open_tables和Open_tables，用以判斷是否須要增長table_cache的值，即若是Open_tables接近table_cache的時候，而且Opened_tables這個值在逐步增長，那就要考慮增長這個值的大小了。

external-locking = FALSE  #MySQL選項能夠避免外部鎖定。True爲開啓。

max_allowed_packet=16M  #服務器一次能處理最大的查詢包的值，也是服務器程序可以處理的最大查詢

sort_buffer_size = 1M  #設置查詢排序時所能使用的緩衝區大小，系統默認大小爲2MB。

注意：該參數對應的分配內存是每一個鏈接獨佔的，若是有100個鏈接，那麼實際分配的總排序緩衝區大小爲100 x6=600MB。因此，對於內存在4GB左右的服務器來講，推薦將其設置爲6MB~8MB

join_buffer_size = 8M #聯合查詢操做所能使用的緩衝區大小，和sort_buffer_size同樣，該參數對應的分配內存也是每一個鏈接獨享。

thread_cache_size = 64 #設置Thread Cache池中能夠緩存的鏈接線程最大數量，可設置爲0~16384，默認爲0.這個值表示能夠從新利用保存在緩存中線程的數量，當斷開鏈接時若是緩存中還有空間，那麼客戶端的線程將被放到緩存中;若是線程從新被請求，那麼請求將從緩存中讀取,若是緩存中是空的或者是新的請求，那麼這個線程將被從新建立，若是有不少線程，增長這個值能夠改善系統性能。經過比較Connections和Threads_created狀態的變量，能夠看到這個變量的做用。咱們能夠根據物理內存設置規則以下:1GB內存咱們配置爲8,2GB內存咱們配置爲16,3GB咱們配置爲32,4GB或4GB以上咱們給此值爲64或更大的值。

thread_concurrency =8  #該參數取值爲服務器邏輯CPU數量x 2，在本例中，服務器有兩個物理CPU，而每一個物理CPU又支持H.T超線程，因此實際取值爲4x 2 = 8。這也是雙四核主流服務器的配置。

query_cache_size = 64M #指定MySQL查詢緩衝區的大小。能夠經過在MySQL控制檯觀察，若是Qcache_lowmem_prunes的值很是大，則代表常常出現緩衝不夠的狀況;若是Qcache_hits的值很是大，則代表查詢緩衝使用得很是頻繁。另外若是改值較小反而會影響效率，那麼能夠考慮不用查詢緩衝。對於Qcache_free_blocks，若是該值很是大，則代表緩衝區中碎片不少。

query_cache_limit =2M  #只有小於此設置值的結果纔會被緩存

query_cache_min_res_unit =2k  #設置查詢緩存分配內存的最小單位，要適當第設置此參數，能夠作到爲減小內存快的申請和分配次數，可是設置過大可能致使內存碎片數值上升。默認值爲4K，建議設置爲1K~16K。

default_table_type =InnoDB  #默認表的類型爲InnoDB

thread_stack = 256K  #設置MySQL每一個線程的堆棧大小，默認值足夠大，可知足普通操做。可設置範圍爲128KB至4GB，默認爲192KB

#transaction_isolation =Level #數據庫隔離級別 (READUNCOMMITTED(讀取未提交內容) READ COMMITTED(讀取提交內容) REPEATABLE READ(可重讀) SERIALIZABLE(可串行化))

tmp_table_size = 64M  #設置內存臨時表最大值。若是超過該值，則會將臨時表寫入磁盤，其範圍1KB到4GB。

max_heap_table_size =64M  #獨立的內存表所容許的最大容量。

table_cache = 614 #給常常訪問的表分配的內存，物理內存越大，設置就越大。調大這個值，通常狀況下能夠下降磁盤IO，但相應的會佔用更多的內存,這裏設置爲614。

table_open_cache = 512  #設置表高速緩存的數目。每一個鏈接進來，都會至少打開一個表緩存。所以，table_cache 的大小應與 max_connections 的設置有關。例如，對於200 個並行運行的鏈接，應該讓表的緩存至少有 200 × N ，這裏 N 是應用能夠執行的查詢的一個聯接中表的最大數量。此外，還須要爲臨時表和文件保留一些額外的文件描述符。

long_query_time = 1  #慢查詢的執行用時上限,默認設置是10s,推薦(1s~2s)

log_long_format  #沒有使用索引的查詢也會被記錄。(推薦,根據業務來調整)

log-slow-queries =/data/3306/slow.log  #慢查詢日誌文件路徑(若是開啓慢查詢,建議打開此日誌)

log-bin =/data/3306/mysql-bin #logbin數據庫的操做日誌,例如update、delete、create等都會存儲到binlog日誌,經過logbin能夠實現增量恢復

relay-log =/data/3306/relay-bin #relay-log日誌記錄的是從服務器I/O線程將主服務器的二進制日誌讀取過來記錄到從服務器本地文件,而後SQL線程會讀取relay-log日誌的內容並應用到從服務器

relay-log-info-file =/data/3306/relay-log.info  #從服務器用於記錄中繼日誌相關信息的文件,默認名爲數據目錄中的relay-log.info。

binlog_cache_size =4M  #在一個事務中binlog爲了記錄sql狀態所持有的cache大小，若是你常用大的，多聲明的事務，能夠增長此值來獲取更大的性能，全部從事務來的狀態都被緩衝在binlog緩衝中，而後再提交後一次性寫入到binlog中，若是事務比此值大，會使用磁盤上的臨時文件來替代，此緩衝在每一個連接的事務第一次更新狀態時被建立。

max_binlog_cache_size = 8M  #最大的二進制Cache日誌緩衝尺寸。

max_binlog_size = 1G  #二進制日誌文件的最大長度(默認設置1GB)一個二進制文件信息超過了這個最大長度以前,MySQL服務器會自動提供一個新的二進制日誌文件接續上。

expire_logs_days = 7  #超過7天的binlog,mysql程序自動刪除(若是數據重要,建議不要開啓該選項)

key_buffer_size =256M  #指定用於索引的緩衝區大小，增長它可獲得更好的索引處理性能。對於內存在4GB左右的服務器來講，該參數可設置爲256MB或384MB。

注意：若是該參數值設置得過大反而會使服務器的總體效率下降！

read_buffer_size = 4M  #讀查詢操做所能使用的緩衝區大小。和sort_buffer_size同樣，該參數對應的分配內存也是每一個鏈接獨享。

read_rnd_buffer_size = 16M #設置進行隨機讀的時候所使用的緩衝區。此參數和read_buffer_size所設置的Buffer相反，一個是順序讀的時候使用，一個是隨機讀的時候使用。可是二者都是針對與線程的設置，每一個線程均可以產生兩種Buffer中的任何一個。默認值256KB，最大值4GB。

bulk_insert_buffer_size =8M  #若是常常性的須要使用批量插入的特殊語句來插入數據,能夠適當調整參數至16MB~32MB,建議8MB。

#myisam_sort_buffer_size =8M #設置在REPAIR Table或用Create index建立索引或 Alter table的過程當中排序索引所分配的緩衝區大小，可設置範圍4Bytes至4GB，默認爲8MB

lower_case_table_names =1  #實現MySQL不區分大小。(發開需求-建議開啓)

slave-skip-errors =1032,1062 #從庫能夠跳過的錯誤數字值(mysql錯誤以數字代碼反饋,全的mysql錯誤代碼大全,之後會發布至博客)。

replicate-ignore-db=mysql  #在作主從的狀況下,設置不須要同步的庫。

server-id = 1  #表示本機的序列號爲1,若是作主從，或者多實例,serverid必定不能相同。

myisam_sort_buffer_size = 128M  #當須要對於執行REPAIR, OPTIMIZE, ALTER 語句重建索引時，MySQL會分配這個緩存，以及LOAD DATA INFILE會加載到一個新表，它會根據最大的配置認真的分配的每一個線程。 

myisam_max_sort_file_size = 10G #當從新建索引（REPAIR，ALTER，TABLE，或者LOAD，DATA，TNFILE）時，MySQL被容許使用臨時文件的最大值。

myisam_repair_threads = 1 #若是一個表擁有超過一個索引, MyISAM 能夠經過並行排序使用超過一個線程去修復他們.

myisam_recover #自動檢查和修復沒有適當關閉的 MyISAM 表.

innodb_additional_mem_pool_size =4M #用來設置InnoDB存儲的數據目錄信息和其餘內部數據結構的內存池大小。應用程序裏的表越多，你須要在這裏面分配越多的內存。對於一個相對穩定的應用，這個參數的大小也是相對穩定的，也沒有必要預留很是大的值。若是InnoDB用廣了這個池內的內存，InnoDB開始從操做系統分配內存，而且往MySQL錯誤日誌寫警告信息。默認爲1MB，當發現錯誤日誌中已經有相關的警告信息時，就應該適當的增長該參數的大小。

innodb_buffer_pool_size =64M #InnoDB使用一個緩衝池來保存索引和原始數據，設置越大，在存取表裏面數據時所須要的磁盤I/O越少。強烈建議不要武斷地將InnoDB的Buffer Pool值配置爲物理內存的50%~80%，應根據具體環境而定。

innodb_data_file_path =ibdata1:128M:autoextend  #設置配置一個可擴展大小的尺寸爲128MB的單獨文件，名爲ibdata1.沒有給出文件的位置，因此默認的是在MySQL的數據目錄內。

innodb_file_io_threads =4  #InnoDB中的文件I/O線程。一般設置爲4，若是是windows能夠設置更大的值以提升磁盤I/O

innodb_thread_concurrency =8 #你的服務器有幾個CPU就設置爲幾，建議用默認設置，通常設爲8。

innodb_flush_log_at_trx_commit =1 #設置爲0就等於innodb_log_buffer_size隊列滿後在統一存儲，默認爲1，也是最安全的設置。

innodb_log_buffer_size =2M  #默認爲1MB，一般設置爲8~16MB就足夠了。

innodb_log_file_size =32M  #肯定日誌文件的大小，更大的設置能夠提升性能，但也會增長恢復數據庫的時間。

innodb_log_files_in_group =3 #爲提升性能,MySQL能夠以循環方式將日誌文件寫到多個文件。推薦設置爲3。

innodb_max_dirty_pages_pct =90 #InnoDB主線程刷新緩存池中的數據。

innodb_lock_wait_timeout =120 #InnoDB事務被回滾以前能夠等待一個鎖定的超時秒數。InnoDB在它本身的鎖定表中自動檢測事務死鎖而且回滾事務。InnoDB用locak tables 語句注意到鎖定設置。默認值是50秒。

innodb_file_per_table =0  #InnoDB爲獨立表空間模式，每一個數據庫的每一個表都會生成一個數據空間。0關閉，1開啓。

獨立表空間優勢：

一、每一個表都有本身獨立的表空間。

二、每一個表的數據和索引都會存在本身的表空間中。

三、能夠實現單表在不一樣的數據庫中移動。

四、空間能夠回收（除drop table操做處，表空不能本身回收。）

[mysqldump]

quick

max_allowed_packet =2M  #設定在網絡傳輸中一次消息傳輸量的最大值。系統默認值爲1MB，最大值是1GB，必須設置爲1024的倍數。單位爲字節。

 

[mysqld_safe]

值得注意：

·        強烈建議不要武斷地將InnoDB的Buffer Pool值配置爲物理內存的50%~80%，應根據具體環境而定。

·        若是key_reads太大，則應該把my.cnf中的key_buffer_size變大，保持key_reads/key_read_re-quests至少在1/100以上，越小越好。

·        若是qcache_lowmem_prunes很大，就要增長query_cache_size的值。

不過不少時候須要具體狀況具體分析，其餘參數的變動咱們能夠等MySQL上線穩定一段時間後在根據status值進行調整。

電商MySQL數據庫配置文件

這是一份電子商務網站MySQL數據庫調整後所運行的配置文件/etc/my.cnf(服務器爲DELL R7十、16GB內存、RAID10)，你們能夠根據實際的MySQL數據庫硬件狀況進行調整配置文件以下：

[client]

port           = 3306

socket         =/data/3306/mysql.sock

default-character-set = utf8

 

[mysqld]

user    = mysql

port    = 3306

character-set-server = utf8

socket =/data/3306/mysql.sock

basedir = /application/mysql

datadir = /data/3306/data

log-error=/data/3306/mysql_err.log

pid-file=/data/3306/mysql.pid

 

log_slave_updates = 1

log-bin = /data/3306/mysql-bin

binlog_format = mixed

binlog_cache_size = 4M

max_binlog_cache_size = 8M

max_binlog_size = 1G

expire_logs_days = 90

binlog-ignore - db = mysql

binlog-ignore - db =information_schema

 

key_buffer_size = 384M

sort_buffer_size = 2M

read_buffer_size = 2M

read_rnd_buffer_size = 16M

join_buffer_size = 2M

thread_cache_size = 8

query_cache_size = 32M

query_cache_limit = 2M

query_cache_min_res_unit = 2k

thread_concurrency = 32

 

table_cache = 614

table_open_cache = 512

open_files_limit   = 10240

back_log = 600

max_connections = 5000

max_connect_errors = 6000

external-locking = FALSE

 

max_allowed_packet =16M

thread_stack = 192K

transaction_isolation =READ-COMMITTED

tmp_table_size = 256M

max_heap_table_size = 512M

 

bulk_insert_buffer_size = 64M

myisam_sort_buffer_size = 64M

myisam_max_sort_file_size = 10G

myisam_repair_threads = 1

myisam_recover

 

long_query_time = 2

slow_query_log

slow_query_log_file =/data/3306/slow.log

skip-name-resolv

skip-locking

skip-networking

server-id = 1

 

innodb_additional_mem_pool_size =16M

innodb_buffer_pool_size = 512M

innodb_data_file_path =ibdata1:256M:autoextend

innodb_file_io_threads = 4

innodb_thread_concurrency = 8

innodb_flush_log_at_trx_commit =2

innodb_log_buffer_size = 16M

innodb_log_file_size = 128M

innodb_log_files_in_group = 3

innodb_max_dirty_pages_pct = 90

innodb_lock_wait_timeout = 120

innodb_file_per_table = 0

 

[mysqldump]

quick

max_allowed_packet = 64M

 

[mysql]

no – auto - rehash

MySQL上線後根據status狀態進行優化

MySQL數據庫上線後，能夠等其穩定運行一段時間後再根據服務器的status狀態進行適當優化，咱們能夠用以下命令列出MySQL服務器運行的各類狀態值：

mysql > show global status;

我我的比較喜歡的用法是 showstatus like '查詢%';

1.慢查詢

有時咱們爲了定位系統中效率比較低下的Query語法，須要打開慢查詢日誌，也就是Slow Que-ry log。打開慢查詢日誌的相關命令以下：

mysql> show variableslike'%slow%';

+---------------------+-----------------------------------------+

|Variable_name      |Value                                  |

+---------------------+-----------------------------------------+

|log_slow_queries    |ON                                    |

|slow_launch_time    |2                                      |

+---------------------+-----------------------------------------+

 

mysql> show globalstatuslike '%slow%';

+---------------------+-------+

|Variable_name       | Value|

+---------------------+-------+

| Slow_launch_threads |0    |

| Slow_queries       | 2128   |

+---------------------+-------+

打開慢查詢日誌可能會對系統性能有一點點影響，若是你的MySQL是主從結構，能夠考慮打開其中一臺從服務器的慢查詢日誌，這樣既能夠監控慢查詢，對系統性能影響也會很小。另外，能夠用MySQL自帶的命令mysqldumpslow進行查詢。好比：下面的命令能夠查出訪問次數最多的20個SQL語句：

mysqldumpslow-s c -t 20host-slow.log

2.鏈接數

咱們若是常常碰見MySQL：ERROR1040：Too manyconnections的狀況，一種狀況是訪問量確實很高，MySQL服務器扛不住了，這個時候就要考慮增長從服務器分散讀壓力。另一種狀況是MySQL配置文件中max_connections的值太小。來看一個例子。

mysql>show variableslike'max_connections';

+-----------------+-------+

| Variable_name   |Value |

+-----------------+-------+

| max_connections |800   |

+-----------------+-------+

這臺服務器最大鏈接數是256，而後查詢一下該服務器響應的最大鏈接數；

mysql> show global status like'Max_used_connections';

+----------------------+-------+

|Variable_name        | Value|

+----------------------+-------+

| Max_used_connections |245   |

+----------------------+-------+

MySQL服務器過去的最大鏈接數是245，沒有達到服務器鏈接數的上線800，不會出現1040錯誤。

Max_used_connections/max_connections* 100% = 85%

最大鏈接數占上限鏈接數的85%左右,若是發現比例在10%如下，則說明MySQL服務器鏈接數的上限設置得太高了。

3.key_buffer_size

key_buffer_size是設置MyISAM表索引緩存空間的大小，此參數對MyISAM表性能影響最大。下面是一臺MyISAM爲主要存儲引擎服務器的配置：

mysql> show variables like'key_buffer_size';

+-----------------+-----------+

| Variable_name   |Value   |

+-----------------+-----------+

| key_buffer_size | 536870912 |

+-----------------+-----------+

從上面能夠看出，分配了512MB內存給key_buffer_size。再來看key_buffer_size的使用狀況：

mysql> show global status like'key_read%';

+-------------------+--------------+

|Variable_name     | Value |

+-------------------+-------+

| Key_read_requests |27813678766 |

|Key_reads          | 6798830      |

+-------------------+--------------+

一共有27813678766個索引讀取請求，有6798830個請求在內存中沒有找到，直接從硬盤讀取索引。

key_cache_miss_rate = key_reads/key_read_requests * 100%

好比上面的數據，key_cache_miss_rate爲0.0244%，4000%個索引讀取請求才有一個直接讀硬盤，效果已經很好了，key_cache_miss_rate在0.1%如下都很好，若是key_cache_miss_rate在0.01%如下的話，則說明key_buffer_size分配得過多，能夠適當減小。

4.臨時表

當執行語句時，關於已經被建立了隱含臨時表的數量，咱們能夠用以下命令查詢其具體狀況：

mysql> show global status like'created_tmp%';

+-------------------------+----------+

|Variable_name          |Value |

+-------------------------+----------+

| Created_tmp_disk_tables |21119   |

|Created_tmp_files      |6     |

|Created_tmp_tables      |17715532  |

+-------------------------+----------+

每次建立臨時表時，Created_tmp_table都會增長，若是磁盤上建立臨時表，Created_tmp_disk_tables也會增長。Created_tmp_files表示MySQL服務建立的臨時文件數，比較理想的配置是：

Created_tmp_disk_tables/Created_tmp_files * 100% <= 25%

好比上面的服務器Created_tmp_disk_tables/Created_tmp_files * 100% =1.20%，就至關不錯。咱們在看一下MySQL服務器對臨時表的配置：

mysql> show variables whereVariable_name in('tmp_table_size','max_heap_table_size');

+---------------------+---------+

|Variable_name       |Value   |

+---------------------+---------+

| max_heap_table_size | 2097152 |

|tmp_table_size      |2097152 |

+---------------------+---------+

5.打開表的狀況

Open_tables表示打開表的數量，Opened_tables表示打開過的表數量，咱們能夠用以下命令查看其具體狀況：

mysql> show global status like'open%tables%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Open_tables   |351   |

| Opened_tables | 1455 |

若是Opened_tables數量過大，說明配置中table_open_cache的值可能過小。咱們查詢下服務器table_open_cache;

mysql> show variables like'table_open_cache'; 

+------------------+-------+

| Variable_name   | Value |

+------------------+-------+

| table_open_cache | 2048  |

+------------------+-------+

比較合適的值爲：

open_tables/ opened_tables* 100%> = 85%

open_tables/ table_open_cache*100% < = 95%

6.進程使用狀況

若是咱們在MySQL服務器的配置文件中設置了thread_cache_size，當客戶端斷開時，服務器處理此客戶請求的線程將會緩存起來以響應一下客戶而不是銷燬(前提是緩存數未達上線)Thread_created表示建立過的線程數，咱們能夠用以下命令查看：

mysql> show global status like'thread%';

+-------------------+-------+

|Variable_name     | Value |

+-------------------+-------+

|Threads_cached    | 40    |

| Threads_connected |1     |

| Threads_created   |330   |

| Threads_running   |1     |

+-------------------+-------+

若是發現Threads_created的值過大的話，代表MySQL服務器一直在建立線程，這也是比較耗費資源的，能夠適當增大配置文件中thread_cache_size的值。查詢服務器thread_cache_size配置以下：

mysql> show variables like'thread_cache_size';

+-------------------+-------+

| Variable_name    | Value |

+-------------------+-------+

| thread_cache_size |100   |

+-------------------+-------+

示例中的MySQL服務器仍是挺健康的。

7.查詢緩存(querycache)

它主要涉及兩個參數，query_cache_size是設置MySQL的Query Cache大小，query_cache_type是設置使用查詢緩存的類型，咱們能夠用以下命令查看其具體狀況：

mysql> show global status like'qcache%';

+-------------------------+-----------+

|Variable_name          |Value  |

+-------------------------+-----------+

|Qcache_free_blocks      |22756    |

|Qcache_free_memory      |76764704  |

| Qcache_hits            | 213028692   |

|Qcache_inserts         |208894227   |

|Qcache_lowmem_prunes    |4010916    |

|Qcache_not_cached      |13385031    |

| Qcache_queries_in_cache |43560    |

|Qcache_total_blocks     |111212    |

+-------------------------+-----------+

 

MySQL查詢緩存變量的相關解釋以下：

Qcache_free_blocks： 緩存中相領內存快的個數。數目大說明可能有碎片。flush query cache會對緩存中的碎片進行整理，從而獲得一個空間塊。

Qcache_free_memory：緩存中的空閒空間。

Qcache_hits：多少次命中。經過這個參數能夠查看到Query Cache的基本效果。

Qcache_inserts：插入次數，沒插入一次查詢時就增長1。命中次數除以插入次數就是命中比率。

Qcache_lowmem_prunes：多少條Query由於內存不足而被清楚出Query Cache。經過Qcache_lowmem_prunes和Query_free_memory相互結合，可以更清楚地瞭解到系統中QueryCache的內存大小是否真的足夠，是否很是頻繁地出現由於內存不足而有Query被換出的狀況。   

Qcache_not_cached：不適合進行緩存的查詢數量，一般是因爲這些查詢不是select語句或用了now()之類的函數。

Qcache_queries_in_cache：當前緩存的查詢和響應數量。

Qcache_total_blocks：緩存中塊的數量。

 

咱們在查詢一下服務器上關於query_cache的配置命令：

mysql> show variables like'query_cache%';

+------------------------------+---------+

|Variable_name               |Value   |

+------------------------------+---------+

|query_cache_limit           |1048576 |

|query_cache_min_res_unit    | 2048    |

|query_cache_size            |2097152 |

|query_cache_type            |ON      |

| query_cache_wlock_invalidate |OFF     |

+------------------------------+---------+

字段解釋以下：

query_cache_limit：超過此大小的查詢將不緩存。

query_cache_min_res_unit：緩存塊的最小值。

query_cache_size：查詢緩存大小。

query_cache_type：緩存類型，決定緩存什麼樣的查詢，示例中表示不緩存select sql_no_cache查詢。

query_cache_wlock_invalidat：表示當有其餘客戶端正在對MyISAM表進行寫操做，讀請求是要等WRITELOCK釋放資源後再查詢仍是容許直接從Query Cache中讀取結果，默認爲OFF（能夠直接從Query Cache中取得結果。）

 

query_cache_min_res_unit的配置是一柄雙刃劍，默認是4KB，設置值大對大數據查詢有好處，但若是你的查詢都是小數據查詢，就容易形成內存碎片和浪費。

 

查詢緩存碎片率 =Qcache_free_blocks/Qcache_total_blocks * 100%

若是查詢碎片率超過20%，能夠用 flushquery cache 整理緩存碎片，或者試試減小query_cache_min_res_unit，若是你查詢都是小數據庫的話。

 

查詢緩存利用率 =(Qcache_free_size– Qcache_free_memory)/query_cache_size * 100%

查詢緩存利用率在25%一下的話說明query_cache_size設置得過大，可適當減小;查詢緩存利用率在80%以上並且Qcache_lowmem_prunes> 50的話則說明query_cache_size可能有點小，否則就是碎片太多。

 

查詢命中率 = (Qcache_hits-Qcache_insert)/Qcache)hits * 100%

示例服務器中的查詢緩存碎片率等於20%左右，查詢緩存利用率在50%，查詢命中率在2%，說明命中率不好，可能寫操做比較頻繁，並且可能有些碎片。

8.排序使用狀況

它表示系統中對數據進行排序時所用的Buffer，咱們能夠用以下命令查看：

mysql> show global status like'sort%';

+-------------------+----------+

| Variable_name    | Value |

+-------------------+----------+

| Sort_merge_passes |10        |

|Sort_range        | 37431240   |

|Sort_rows         | 6738691532|

|Sort_scan         |1823485     |

+-------------------+----------+

Sort_merge_passes包括以下步驟：MySQL首先會嘗試在內存中作排序，使用的內存大小由系統變量sort_buffer_size來決定，若是它不夠大則把全部的記錄都讀在內存中，而MySQL則會把每次在內存中排序的結果存到臨時文件中，等MySQL找到全部記錄以後，再把臨時文件中的記錄作一次排序。此次再排序就會增長sort_merge_passes。實際上，MySQL會用另一個臨時文件來存儲再次排序的結果，因此咱們一般會看到sort_merge_passes增長的數值是建臨時文件數的兩倍。由於用到了臨時文件，因此速度可能會比較慢，增大sort_buffer_size會減小sort_merge_passes和建立臨時文件的次數，但盲目地增大sort_buffer_size並不必定能提升速度。

9.文件打開數(open_files)

咱們如今處理MySQL故障時，發現當Open_files大於open_files_limit值時，MySQL數據庫就會發生卡住的現象，致使Nginx服務器打不開相應頁面。這個問題你們在工做中應注意，咱們能夠用以下命令查看其具體狀況：

show global status like'open_files';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Open_files    |1481   |

+---------------+-------+

mysql> show global status like'open_files_limit';

+------------------+-------+

| Variable_name   | Value |

+------------------+--------+

| Open_files_limit | 4509 |

+------------------+--------+

比較合適的設置是：Open_files/Open_files_limit * 100% < = 75%

10.InnoDB_buffer_pool_cache合理設置

InnoDB存儲引擎的緩存機制和MyISAM的最大區別就在於，InnoDB不只僅緩存索引，同時還會緩存實際的數據。此參數用來設置InnoDB最主要的Buffer的大小，也就是緩存用戶表及索引數據的最主要緩存空間，對InnoDB總體性能影響也最大。

不管是MySQL官方手冊仍是網絡上許多人分享的InnoDB優化建議，都是簡單地建議將此值設置爲整個系統物理內存的50%~80%。這種作法其實不妥，咱們應根據實際的運行場景來正確設置此項參數。

MySQL優化小思想

不少時候咱們會發現，經過參數設置進行性能優化所帶來的性能提高，並不如許多人想象的那樣會產生質的飛躍，除非是以前的設置存在嚴重不合理的狀況。咱們不能將性能調優徹底依託與經過DBA在數據庫上線後進行參數調整，而應該在系統設計和開發階段就儘量減小性能問題。(重點在於前期架構合理的設計及開發的程序合理)

MySQL數據庫的可擴展架構方案

若是憑藉MySQL的優化任沒法頂住壓力，這個時候咱們就必須考慮MySQL的可擴展性架構了(有人稱爲MySQL集羣)它有如下明顯的優點：

·        成本低，很容易經過價格低廉Pc server搭建出一個處理能力很是強大的計算機集羣。

·        不太容易遇到瓶頸，由於很容易經過添加主機來增長處理能力。

·        單節點故障對系統的總體影響較小。

目前可行的方案以下：

（1）MySQL Cluter

其特色爲可用性很是高，性能很是好。每份數據至少可在不一樣主機上存一份副本，且冗餘數據拷貝實時同步。但它的維護很是複雜，存在部分Bug，目前還不適合比較核心的線上系統，因此暫時不推薦。

（2）DRBD磁盤網絡鏡像方案

其特色爲軟件功能強大，數據可在底層快設備級別跨物理主機鏡像，且可根據性能可靠性要求配置不一樣級別的同步。I/O操做會保持順序，可知足數據庫對數據一致性的苛刻要求。但非分佈式文件系統環境沒法支持鏡像數據同時可見，性能和可靠性二者互相矛盾，沒法適用於性能和可靠性要求都比較苛刻的環境，維護成本高於MySQL Replication。另外，DRBD是官方推薦的可用於MySQL的搞可用方案之一，你們可根據實際環境來考慮是否部署。

（3）MySQL Replication

在工做中，此種MySQL搞可用、高擴展性架構也是用得最多的，我也推薦此方案，一主多從、雙主多從是生產環境常見的高可用架構方案。

 

高可用架構：MySQL一主多從、MySQL雙主多從、MySQL讀寫分離、MySQL分佈式集羣、DRBD+Heartbeat+MySQL、等各類集羣架構