1.簡單介紹
InnoDB給MySQL提供了具備提交,回滾和崩潰恢復能力的事務安全(ACID兼容)存儲引擎。InnoDB鎖定在行級而且也在SELECT語句提供一個Oracle風格一致的非鎖定讀。這些特點增長了多用戶部署和性能。沒有在InnoDB中擴大鎖定的須要,由於在InnoDB中行級鎖定適合很是小的空間。InnoDB也支持FOREIGN KEY強制。在SQL查詢中,你能夠自由地將InnoDB類型的表與其它MySQL的表的類型混合起來,甚至在同一個查詢中也能夠混合。html
2.之因此選用innodb做爲存儲引擎的考慮
目前來講,InnoDB是爲Mysql處理巨大數據量時的最大性能設計。它的CPU效率多是任何其它基於磁盤的關係數據庫引擎所不能匹敵的。在數據量大的網站或是應用中Innodb是倍受青睞的。
另外一方面,在數據庫的複製操做中Innodb也是能保證master和slave數據一致有必定的做用。 mysql
3.下面是對線上mysql5.6版本的數據庫的配置進行的優化分析記錄:
1)內存利用方面:
innodb_buffer_pool_size
這個是Innodb最重要的參數,和MyISAM的key_buffer_size有類似之處,但也是有差異的。
這個參數主要緩存innodb表的索引,數據,插入數據時的緩衝。
該參數分配內存的原則:
這個參數默認分配只有8M,能夠說是很是小的一個值。
若是是一個專用DB服務器,那麼他能夠佔到內存的70%-80%。
這個參數不能動態更改,因此分配需多考慮。分配過大,會使Swap佔用過多,導致Mysql的查詢特慢。
若是你的數據比較小,那麼可分配是你的數據大小+10%左右作爲這個參數的值。
例如:數據大小爲50M,那麼給這個值分配innodb_buffer_pool_size=64M
設置方法,在my.cnf文件裏:
innodb_buffer_pool_size=4G
----------------------------------------------------------------------------------------------------------
注意:
在Mysql5.7版本以前,調整innodb_buffer_pool_size大小必須在my.cnf配置裏修改,而後重啓mysql進程才能夠生效。
現在到了Mysql5.7版本,就能夠直接動態調整這個參數,方便了不少。linux
尤爲是在服務器內存增長以後,運維人員不能粗枝大葉,要記得調大Innodb_Buffer_Pool_size這個參數。
數據庫配置後,要注意檢查Innodb_Buffer_Pool_size這個參數的設置是否合理sql
須要注意的地方:
在調整innodb_buffer_pool_size 期間,用戶的請求將會阻塞,直到調整完畢,因此請勿在白天調整,在凌晨3-4點低峯期調整。
調整時,內部把數據頁移動到一個新的位置,單位是塊。若是想增長移動的速度,須要調整innodb_buffer_pool_chunk_size參數的大小,默認是128M。數據庫
Mysql5.7中動態調整這個參數的操做記錄(例如由128M增大爲384M):
134217728/1024*1024=128M
mysql> SELECT @@innodb_buffer_pool_size;緩存
+---------------------------+安全
| @@innodb_buffer_pool_size |性能優化
+---------------------------+服務器
| 134217728 |網絡
+---------------------------+
1 row in set (0.00 sec)
mysql> SELECT @@innodb_buffer_pool_chunk_size;
+---------------------------------+
| @@innodb_buffer_pool_chunk_size |
+---------------------------------+
| 134217728 |
+---------------------------------+
1 row in set (0.00 sec)
mysql> SET GLOBAL innodb_buffer_pool_size=402653184;
Query OK, 0 rows affected (0.01 sec)
mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
| 402653184 |
+---------------------------+
1 row in set (0.00 sec)
innodb_buffer_pool_chunk_size的大小,計算公式是innodb_buffer_pool_size/innodb_buffer_pool_instances
好比如今初始化innodb_buffer_pool_size爲2G,innodb_buffer_pool_instances實例爲4,innodb_buffer_pool_chunk_size設置爲1G,那麼會自動把innodb_buffer_pool_chunk_size 1G調整爲512M.
例:
./mysqld --innodb_buffer_pool_size=2147483648 --innodb_buffer_pool_instances=4
--innodb_buffer_pool_chunk_size=1073741824;
mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
| 2147483648 |
+---------------------------+
1 row in set (0.00 sec)
mysql> SELECT @@innodb_buffer_pool_instances;
+--------------------------------+
| @@innodb_buffer_pool_instances |
+--------------------------------+
| 4 |
+--------------------------------+
1 row in set (0.00 sec)
# Chunk size was set to 1GB (1073741824 bytes) on startup but was
# truncated to innodb_buffer_pool_size / innodb_buffer_pool_instances
mysql> SELECT @@innodb_buffer_pool_chunk_size;
+---------------------------------+
| @@innodb_buffer_pool_chunk_size |
+---------------------------------+
| 536870912 |
+---------------------------------+
1 row in set (0.00 sec)
監控Buffer Pool調整進程
mysql> SHOW STATUS WHERE Variable_name='InnoDB_buffer_pool_resize_status';
+----------------------------------+----------------------------------+
| Variable_name | Value |
+----------------------------------+----------------------------------+
| Innodb_buffer_pool_resize_status | Resizing also other hash tables. |
+----------------------------------+----------------------------------+
1 row in set (0.00 sec)
查看錯誤日誌:
(增大)
[Note] InnoDB: Resizing buffer pool from 134217728 to 4294967296. (unit=134217728)
[Note] InnoDB: disabled adaptive hash index.
[Note] InnoDB: buffer pool 0 : 31 chunks (253952 blocks) was added.
[Note] InnoDB: buffer pool 0 : hash tables were resized.
[Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
[Note] InnoDB: completed to resize buffer pool from 134217728 to 4294967296.
[Note] InnoDB: re-enabled adaptive hash index.
(減小)
[Note] InnoDB: Resizing buffer pool from 4294967296 to 134217728. (unit=134217728)
[Note] InnoDB: disabled adaptive hash index.
[Note] InnoDB: buffer pool 0 : start to withdraw the last 253952 blocks.
[Note] InnoDB: buffer pool 0 : withdrew 253952 blocks from free list. tried to relocate 0 pages. (253952/253952)
[Note] InnoDB: buffer pool 0 : withdrawn target 253952 blocks.
[Note] InnoDB: buffer pool 0 : 31 chunks (253952 blocks) was freed.
[Note] InnoDB: buffer pool 0 : hash tables were resized.
[Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
[Note] InnoDB: completed to resize buffer pool from 4294967296 to 134217728.
[Note] InnoDB: re-enabled adaptive hash index.
----------------------------------------------------------------------------------------------------------
innodb_additional_mem_pool_size
用來存放Innodb的內部目錄,這個值不用分配太大,系統能夠自動調。一般設置16M夠用了,若是表比較多,能夠適當的增大。
設置方法,在my.cnf文件裏:
innodb_additional_mem_pool_size = 16M
2)關於日誌方面:
innodb_log_file_size
做用:指定在一個日誌組中,每一個log的大小。
結合innodb_buffer_pool_size設置其大小,25%-100%。避免不須要的刷新。
注意:這個值分配的大小和數據庫的寫入速度,事務大小,異常重啓後的恢復有很大的關係。通常取256M能夠兼顧性能和recovery的速度。
分配原則:幾個日值成員大小加起來差很少和你的innodb_buffer_pool_size相等。上限爲每一個日值上限大小爲4G.通常控制在幾個Log文件相加大小在2G之內爲佳。具體狀況還須要看你的事務大小,數據大小爲依據。
說明:這個值分配的大小和數據庫的寫入速度,事務大小,異常重啓後的恢復有很大的關係。
設置方法:在my.cnf文件裏:
innodb_log_file_size = 256M
innodb_log_files_in_group
做用:指定你有幾個日值組。
分配原則: 通常咱們能夠用2-3個日值組。默認爲兩個。
設置方法:在my.cnf文件裏:
innodb_log_files_in_group=3
innodb_log_buffer_size:
做用:事務在內存中的緩衝,也就是日誌緩衝區的大小, 默認設置便可,具備大量事務的能夠考慮設置爲16M。
若是這個值增加過快,能夠適當的增長innodb_log_buffer_size
另外若是你須要處理大理的TEXT,或是BLOB字段,能夠考慮增長這個參數的值。
設置方法:在my.cnf文件裏:
innodb_log_buffer_size=3M
innodb_flush_logs_at_trx_commit
做用:控制事務的提交方式,也就是控制log的刷新到磁盤的方式。
分配原則:這個參數只有3個值(0,1,2).默認爲1,性能更高的能夠設置爲0或是2,這樣能夠適當的減小磁盤IO(但會丟失一秒鐘的事務。),遊戲庫的MySQL建議設置爲0。主庫請不要更改了。
其中:
0:log buffer中的數據將以每秒一次的頻率寫入到log file中,且同時會進行文件系統到磁盤的同步操做,可是每一個事務的commit並不會觸發任何log buffer 到log file的刷新或者文件系統到磁盤的刷新操做;
1:(默認爲1)在每次事務提交的時候將logbuffer 中的數據都會寫入到log file,同時也會觸發文件系統到磁盤的同步;
2:事務提交會觸發log buffer 到log file的刷新,但並不會觸發磁盤文件系統到磁盤的同步。此外,每秒會有一次文件系統到磁盤同步操做。
說明:
這個參數的設置對Innodb的性能有很大的影響,因此在這裏給多說明一下。
當這個值爲1時:innodb 的事務LOG在每次提交後寫入日值文件,並對日值作刷新到磁盤。這個能夠作到不丟任何一個事務。
當這個值爲2時:在每一個提交,日誌緩衝被寫到文件,但不對日誌文件作到磁盤操做的刷新,在對日誌文件的刷新在值爲2的狀況也每秒發生一次。但須要注意的是,因爲進程調用方面的問題,並不能保證每秒100%的發生。從而在性能上是最快的。但操做系統崩潰或掉電纔會刪除最後一秒的事務。
當這個值爲0時:日誌緩衝每秒一次地被寫到日誌文件,而且對日誌文件作到磁盤操做的刷新,可是在一個事務提交不作任何操做。mysqld進程的崩潰會刪除崩潰前最後一秒的事務。
從以上分析,當這個值不爲1時,能夠取得較好的性能,但遇到異常會有損失,因此須要根據自已的狀況去衡量。
設置方法:在my.cnf文件裏:
innodb_flush_logs_at_trx_commit=1
3)文件IO分配,空間佔用方面
innodb_file_per_table
做用:使每一個Innodb的表,有自已獨立的表空間。如刪除文件後能夠回收那部分空間。默認是關閉的,建議打開(innodb_file_per_table=1)
分配原則:只有使用不使用。但DB還須要有一個公共的表空間。
設置方法:在my.cnf文件裏:
innodb_file_per_table=1
innodb_file_io_threads
做用:文件讀寫IO數,這個參數只在Windows上起做用。在Linux上只會等於4,默認便可!
設置方法:在my.cnf文件裏:
innodb_file_io_threads=4
innodb_open_files
做用:限制Innodb能打開的表的數據。
分配原則:這個值默認是300。若是庫裏的表特別多的狀況,能夠適當增大爲1000。innodb_open_files的大小對InnoDB效率的影響比較小。可是在InnoDBcrash的狀況下,innodb_open_files設置太小會影響recovery的效率。因此用InnoDB的時候仍是把innodb_open_files放大一些比較合適。
設置方法:在my.cnf文件裏:
innodb_open_files=800
innodb_data_file_path
指定表數據和索引存儲的空間,能夠是一個或者多個文件。最後一個數據文件必須是自動擴充的,也只有最後一個文件容許自動擴充。這樣,當空間用完後,自動擴充數據文件就會自動增加(以8MB爲單位)以容納額外的數據。
例如: innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:50M:autoextend 兩個數據文件放在不一樣的磁盤上。數據首先放在ibdata1 中,當達到900M之後,數據就放在ibdata2中。
設置方法,在my.cnf文件裏:
innodb_data_file_path =ibdata1:1G;ibdata2:1G;ibdata3:1G;ibdata4:1G;ibdata5:1G;ibdata6:1G:autoextend
innodb_data_home_dir
放置表空間數據的目錄,默認在mysql的數據目錄,設置到和MySQL安裝文件不一樣的分區能夠提升性能。
設置方法,在my.cnf文件裏:(好比mysql的數據目錄是/data/mysql/data,這裏能夠設置到不通的分區/home/mysql下)
innodb_data_home_dir = /home/mysql
4)其它相關參數(適當的增長table_cache)
這裏說明一個比較重要的參數:
innodb_flush_method
做用:Innodb和系統打交道的一個IO模型
分配原則:
Windows不用設置。
linux能夠選擇:O_DIRECT
直接寫入磁盤,禁止系統Cache了
設置方法:在my.cnf文件裏:
innodb_flush_method=O_DIRECT
innodb_max_dirty_pages_pct
做用:在buffer pool緩衝中,容許Innodb的髒頁的百分比,值在範圍1-100,默認爲90,建議保持默認。
這個參數的另外一個用處:當Innodb的內存分配過大,導致Swap佔用嚴重時,能夠適當的減少調整這個值,使達到Swap空間釋放出來。建義:這個值最大在90%,最小在15%。太大,緩存中每次更新須要致換數據頁太多,過小,放的數據頁過小,更新操做太慢。
設置方法:在my.cnf文件裏:
innodb_max_dirty_pages_pct=90
動態更改須要有管理員權限:
set global innodb_max_dirty_pages_pct=50;
innodb_thread_concurrency
同時在Innodb內核中處理的線程數量。建議默認值。
設置方法,在my.cnf文件裏:
innodb_thread_concurrency = 16
5)公共參數調優
skip-external-locking
MyISAM存儲引擎也一樣會使用這個參數,MySQL4.0以後,這個值默認是開啓的。
做用是避免MySQL的外部鎖定(老版本的MySQL此參數叫作skip-locking),減小出錯概率加強穩定性。建議默認值。
設置方法,在my.cnf文件裏:
skip-external-locking
skip-name-resolve
禁止MySQL對外部鏈接進行DNS解析(默認是關閉此項設置的,即默認解析DNS),使用這一選項能夠消除MySQL進行DNS解析的時間。
但須要注意,若是開啓該選項,則全部遠程主機鏈接受權都要使用IP地址方式,不然MySQL將沒法正常處理鏈接請求!若是須要,能夠設置此項。
設置方法,在my.cnf文件裏:(我這線上mysql數據庫中打開了這一設置)
skip-name-resolve
max_connections
設置最大鏈接(用戶)數,每一個鏈接MySQL的用戶均算做一個鏈接,max_connections的默認值爲100。此值須要根據具體的鏈接數峯值設定。
設置方法,在my.cnf文件裏:
max_connections = 3000
query_cache_size
查詢緩存大小,若是表的改動很是頻繁,或者每次查詢都不一樣,查詢緩存的結果會減慢系統性能。能夠設置爲0。
設置方法,在my.cnf文件裏:
query_cache_size = 512M
sort_buffer_size
connection級的參數,排序緩存大小。通常設置爲2-4MB便可。
設置方法,在my.cnf文件裏:
sort_buffer_size = 1024M
read_buffer_size
connection級的參數。通常設置爲2-4MB便可。
設置方法,在my.cnf文件裏:
read_buffer_size = 1024M
max_allowed_packet
網絡包的大小,爲避免出現較大的網絡包錯誤,建議設置爲16M
設置方法,在my.cnf文件裏:
max_allowed_packet = 16M
table_open_cache
當某一鏈接訪問一個表時,MySQL會檢查當前已緩存表的數量。若是該表已經在緩存中打開,則會直接訪問緩存中的表,以加快查詢速度;若是該表未被緩存,則會將當前的表添加進緩存並進行查詢。
經過檢查峯值時間的狀態值Open_tables和Opened_tables,能夠決定是否須要增長table_open_cache的值。
若是發現open_tables等於table_open_cache,而且opened_tables在不斷增加,那麼就須要增長table_open_cache的值;設置爲512便可知足需求。
設置方法,在my.cnf文件裏:
table_open_cache = 512
myisam_sort_buffer_size
實際上這個myisam_sort_buffer_size參數意義不大,這是個字面上蒙人的參數,它用於ALTER TABLE, OPTIMIZE TABLE, REPAIR TABLE 等命令時須要的內存。默認值便可。
設置方法,在my.cnf文件裏:
myisam_sort_buffer_size = 8M
thread_cache_size
線程緩存,若是一個客戶端斷開鏈接,這個線程就會被放到thread_cache_size中(緩衝池未滿),SHOW STATUS LIKE 'threads%';若是 Threads_created 不斷增大,那麼當前值設置要改大,改到 Threads_connected 值左右。(一般狀況下,這個值改善性能不大),默認8便可
設置方法,在my.cnf文件裏:
thread_cache_size = 8
innodb_thread_concurrency
線程併發數,建議設置爲CPU內核數*2
設置方法,在my.cnf文件裏:
innodb_thread_concurrency = 8
key_buffer_size
僅做用於 MyISAM存儲引擎,用來設置用於緩存 MyISAM存儲引擎中索引文件的內存區域大小。若是咱們有足夠的內存,這個緩存區域最好是可以存放下咱們全部的 MyISAM 引擎表的全部索引,以儘量提升性能。不要設置超過可用內存的30%。即便不用MyISAM表,也要設置該值8-64M,用於臨時表。
設置方法,在my.cnf文件裏:
key_buffer_size = 8M
-----------影響InnoDB性能的一些重要參數--------------
1)InnoDB_buffer_pool_size
這個參數定義InnoDB存儲引擎的表數據和索引數據的最大內存緩衝區,InnoDB_buffer_pool_size參數同時提供爲數據塊和索引塊作緩存.這個值設置的越高,訪問表中數據須要的磁盤IO就越少.
2)InnoDB_flush_log_at_trx_commit
這個參數控制緩衝區的數據寫入到日誌文件以及日誌文件數據刷新到磁盤的操做時機.在正式環境中建議設置成1。
設置0時日誌緩衝每秒一次被寫到日誌文件,而且對日誌文件作向磁盤刷新的操做,可是在一個事物提交不作任何操做.
設置1時在每一個事物提交時,日誌緩衝被寫到日誌文件,而且對日誌文件作向磁盤刷新的操做
設置2時在每一個事物提交時,日誌緩衝被寫到日誌文件,但不對日誌文件作向磁盤刷新的操做,對日誌文件每秒向磁盤作一次刷新操做.
3)InnoDB_additional_mem_pool_size
這個參數是InnoDB用來存儲數據庫結構和其餘內部數據結構的內存池.應用程序的表越多,則須要從這裏分配越多的內存,若是用光這個池,則會從OS層分配.
4)InnoDB_lock_wait_timeout
這個參數自動檢測行鎖致使的死鎖並進行相應處理,可是對於表鎖致使的死鎖不能自動檢測默認值爲50秒.
5)InnoDB_support_xa
這個參數設置MySQL是否支持分佈式事務
6)InnoDB_log_buffer_size
這個參很多天志緩衝大小
7)InnoDB_log_file_size
這個參數是一個日誌組中每一個日誌文件的大小,此參數在高寫入負載尤爲是大數據集的狀況下很重要.這個值越大則性能相對越高,但好似反作用是一旦系統崩潰恢復的時間會加長.
8)Innodb_io_capacity
這個參數刷新髒頁數量和合並插入數量,改善磁盤IO處理能力
9)Innodb_use_native_aio
異步I/O在必定程度上提升系統的併發能力,在Linux系統上,能夠經過將MySQL的服務器此參數的值設定爲ON設定InnoDB可使用Linux的異步I/O子系統.
10)Innodb_read_io_threads
這個參數可調整的讀請求的後臺線程數
11)Innodb_write_io_threads
這個參數可調整的寫請求的後臺線程數
12)InnoDB_buffer_pool_instances
這個參數能較好的運行於多核處理器,支持使用 此參數對服務器變量創建多個緩衝池實例,每一個緩衝池實例分別自我管理空閒列表、列表刷寫、LRU以及其它跟緩衝池相關的數據結構,並經過各自的互斥鎖進行保護
13)InnoDB_purge_threads
MySQL5.5之前碎片回收操做是主線程的一部分,這經按期調度的方式運行,但會阻塞數據庫的其餘操做.到5.5之後,能夠將這個線程獨立出來 ;這個能讓碎片回收得更及時並且不影響其餘線程的操做
14)Innodb_flush_method
這個參數控制着innodb數據文件及redo log的打開、刷寫模式,對於這個參數,文檔上是這樣描述的:
有三個值:fdatasync(默認),O_DSYNC,O_DIRECT
默認是fdatasync,調用fsync()去刷數據文件與redo log的buffer
爲O_DSYNC時,innodb會使用O_SYNC方式打開和刷寫redo log,使用fsync()刷寫數據文件
爲O_DIRECT時,innodb使用O_DIRECT打開數據文件,使用fsync()刷寫數據文件跟redo log
總結一下三者寫數據方式:
fdatasync模式:寫數據時,write這一步並不須要真正寫到磁盤纔算完成(可能寫入到操做系統buffer中就會返回完成),真正完成是flush操做,buffer交給操做系統去flush,而且文件的元數據信息也都須要更新到磁盤。
O_DSYNC模式:寫日誌操做是在write這步完成,而數據文件的寫入是在flush這步經過fsync完成
O_DIRECT模式:數據文件的寫入操做是直接從mysql innodb buffer到磁盤的,並不用經過操做系統的緩衝,而真正的完成也是在flush這步,日誌仍是要通過OS緩衝
使用下面命令就能夠查看到上面參數的設置:
mysql> show variables like "%innodb%";
-----------------------------------------------------------------------------------------------------------------------------------------------
下面是線上mysql(innodb)的my.cnf配置參考:
[client]
port = 3306
socket = /usr/local/mysql/var/mysql.sock
[mysqld]
port = 3306
socket = /usr/local/mysql/var/mysql.sock
basedir = /usr/local/mysql/
datadir = /data/mysql/data
pid-file = /data/mysql/data/mysql.pid
user = mysql
bind-address = 0.0.0.0
server-id = 1
sync_binlog=1
log_bin = mysql-bin
skip-name-resolve
back_log = 600
max_connections = 3000
max_connect_errors = 3000
table_open_cache = 512
max_allowed_packet = 16M
binlog_cache_size = 16M
max_heap_table_size = 16M
tmp_table_size = 256M
read_buffer_size = 1024M
read_rnd_buffer_size = 1024M
sort_buffer_size = 1024M
join_buffer_size = 1024M
key_buffer_size = 8192M
thread_cache_size = 8
query_cache_size = 512M
query_cache_limit = 1024M
ft_min_word_len = 4
binlog_format = mixed
expire_logs_days = 30
log_error = /data/mysql/data/mysql-error.log
slow_query_log = 1
long_query_time = 1
slow_query_log_file = /data/mysql/data/mysql-slow.log
performance_schema = 0
explicit_defaults_for_timestamp
skip-external-locking
default_storage_engine = InnoDB
innodb_file_per_table = 1
innodb_open_files = 500
innodb_buffer_pool_size = 1024M
innodb_write_io_threads = 1000
innodb_read_io_threads = 1000
innodb_thread_concurrency = 8
innodb_purge_threads = 1
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 4M
innodb_log_file_size = 32M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120
bulk_insert_buffer_size = 8M
myisam_sort_buffer_size = 8M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
interactive_timeout = 28800
wait_timeout = 28800
[mysqldump]
quick
max_allowed_packet = 16M
[myisamchk]
key_buffer_size = 8M
sort_buffer_size = 8M
read_buffer = 4M
write_buffer = 4M
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
port = 3306
--------------------------------------------------------------------------------------------------------------------------------------
下面分享一個mysql5.6下my.cnf的優化配置,能使mysql性能大大提高:
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the
# *** default location during install, and will be replaced if you
# *** upgrade to a newer version of MySQL.
[mysqld]
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
# These are commonly set, remove the # and set as required.
# basedir = .....
# datadir = .....
# port = .....
# server_id = .....
# socket = .....
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
##################################################
#innodb
user=mysql
innodb_buffer_pool_size=6G
innodb_log_file_size=4G
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit=2
innodb_file_per_table=1
innodb_file_io_threads=4
innodb_flush_method=O_DIRECT
innodb_io_capacity=2000
innodb_io_capacity_max=6000
innodb_lru_scan_depth=2000
innodb_thread_concurrency = 0
innodb_additional_mem_pool_size=16M
innodb_autoinc_lock_mode = 2
##################################################
# Binary log/replication
log-bin
sync_binlog=1
sync_relay_log=1
relay-log-info-repository=TABLE
master-info-repository=TABLE
expire_logs_days=7
binlog_format=ROW
transaction-isolation=READ-COMMITTED
#################################################
#cache
tmp_table_size=512M
character-set-server=utf8
collation-server=utf8_general_ci
skip-external-locking
back_log=1024
key_buffer_size=1024M
thread_stack=256k
read_buffer_size=8M
thread_cache_size=64
query_cache_size=128M
max_heap_table_size=256M
query_cache_type=1
binlog_cache_size = 2M
table_open_cache=128
thread_cache=1024
thread_concurrency=8
wait_timeout=30
join_buffer_size = 1024M
sort_buffer_size = 8M
read_rnd_buffer_size = 8M
#################################################
#connect
max-connect-errors=100000
max-connections=1000
#################################################
explicit_defaults_for_timestamp=true
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
##################################################
參數解釋:
# Binary log/replication(這裏主要是複製功能,也就是主從,提早配置好,後面講主從配置)
#二進制日誌
log-bin
#爲了在最大程序上保證複製的InnoDB事務持久性和一致性
sync_binlog=1
sync_relay_log=1
#啓用此兩項,可用於實如今崩潰時保證二進制及從服務器安全的功能
relay-log-info-repository=TABLE
master-info-repository=TABLE
#設置清除日誌時間
expire_logs_days=7
#行復制
binlog_format=ROW
#mysql數據庫事務隔離級別有四種(READ UNCOMMITTED,READ COMMITTED,REPEATABLE READ,SERIALIZABLE)
transaction-isolation=READ-COMMITTED
#cache
#內部內存臨時表的最大值
tmp_table_size=512M
character-set-server=utf8
collation-server=utf8_general_ci
#即跳過外部鎖定
skip-external-locking
#MySQL能暫存的鏈接數量(根據實際設置)
back_log=1024
#指定索引緩衝區的大小,只對MyISAM表起做用,這裏寫上也沒有關係
key_buffer_size=1024M
#這條指令限定用於每一個數據庫線程的棧大小
thread_stack=256k
#當一個查詢不斷地掃描某一個表,MySQL會爲它分配一段內存緩衝區
read_buffer_size=8M
#線程緩存
thread_cache_size=64
#查詢緩存大小
query_cache_size=128M
#內部內存臨時表的最大值,每一個線程都要分配
max_heap_table_size=256M
#將查詢結果放入查詢緩存中
query_cache_type=1
#表明在事務過程當中容納二進制日誌SQL語句的緩存大小
binlog_cache_size = 2M
#一樣是緩存表大小
table_open_cache=128
#緩存線程
thread_cache=1024
#推薦設置爲服務器 CPU核數的2倍
thread_concurrency=8
wait_timeout=30
#表和表聯接的緩衝區的大小
join_buffer_size = 1024M
#是一個connection級參數,在每一個connection第一次須要使用這個buffer的時候,一次性分配設置的內存
sort_buffer_size=8M
#隨機讀取數據緩衝區使用內存
read_rnd_buffer_size = 8M
#connect
#是一個MySQL中與安全有關的計數器值,它負責阻止過多嘗試失敗的客戶端以防止暴力破解密碼
max-connect-errors=100000
#鏈接數
max-connections=1000
#開啓查詢緩存
explicit_defaults_for_timestamp=true
#mysql服務器可以工做在不一樣的模式下,並能針對不一樣的客戶端以不一樣的方式應用這些模式
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
下面列出了對性能優化影響較大的主要變量,主要分爲鏈接請求的變量和緩衝區變量。
1.鏈接請求的變量:
1) max_connections
MySQL的最大鏈接數,增長該值增長mysqld 要求的文件描述符的數量。若是服務器的併發鏈接請求量比較大,建議調高此值,以增長並行鏈接數量,固然這創建在機器能支撐的狀況下,由於若是鏈接數越多, 介於MySQL會爲每一個鏈接提供鏈接緩衝區,就會開銷越多的內存,因此要適當調整該值,不能盲目提升設值。
數值太小會常常出現ERROR 1040: Too many connections錯誤,能夠過’conn%’通配符查看當前狀態的鏈接數量,以定奪該值的大小。
show variables like ‘max_connections’ 最大鏈接數
show status like ‘max_used_connections’響應的鏈接數
以下:
mysql> show variables like ‘max_connections‘;
+———————–+——-+
| Variable_name | Value |
+———————–+——-+
| max_connections | 256 |
+———————–+——-+
mysql> show status like ‘max%connections‘;
+———————–+——-+
| Variable_name | Value |
+—————————-+——-+
| max_used_connections | 256|
+—————————-+——-+
max_used_connections / max_connections * 100% (理想值≈ 85%)
若是max_used_connections跟max_connections相同 那麼就是max_connections設置太低或者超過服務器負載上限了,低於10%則設置過大。
2) back_log
MySQL能暫存的鏈接數量。當主要MySQL線程在一個很短期內獲得很是多的鏈接請求,這就起做用。若是MySQL的鏈接數據達到 max_connections時,新來的請求將會被存在堆棧中,以等待某一鏈接釋放資源,該堆棧的數量即back_log,若是等待鏈接的數量超過 back_log,將不被授予鏈接資源。
back_log值指出在MySQL暫時中止回答新請求以前的短期內有多少個請求能夠被存在堆棧中。只有若是指望在一個短期內有不少鏈接,你須要增長它,換句話說,這值對到來的TCP/IP鏈接的偵聽隊列的大小。
當觀察你主機進程列表(mysql> show full processlist),發現大量264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待鏈接進程時,就要加大back_log 的值了。
默認數值是50,可調優爲128,對系統設置範圍爲小於512的整數。
3) interactive_timeout
一個交互鏈接在被服務器在關閉前等待行動的秒數。一個交互的客戶被定義爲對mysql_real_connect()使用CLIENT_INTERACTIVE 選項的客戶。
默認數值是28800,可調優爲7200。
2. 緩衝區變量
全局緩衝:
4) key_buffer_size
key_buffer_size指定索引緩衝區的大小,它決定索引處理的速度,尤爲是索引讀的速度。經過檢查狀態值 Key_read_requests和Key_reads,能夠知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該儘量的低,至少是1:100,1:1000更好(上述狀態值可使用SHOW STATUS LIKE ‘key_read%’得到)。
key_buffer_size只對MyISAM表起做用。即便你不使用MyISAM表,可是內部的臨時磁盤表是MyISAM表,也要使用該值。可使用檢查狀態值created_tmp_disk_tables得知詳情。
舉例以下:
mysql> show variables like ‘key_buffer_size‘;
+——————-+————+
| Variable_name | Value |
+———————+————+
| key_buffer_size | 536870912 |
+———— ———-+————+
key_buffer_size爲512MB,咱們再看一下key_buffer_size的使用狀況:
mysql> show global status like ‘key_read%‘;
+————————+————-+
| Variable_name | Value |
+————————+————-+
| Key_read_requests| 27813678764 |
| Key_reads | 6798830 |
+————————+————-+
一共有27813678764個索引讀取請求,有6798830個請求在內存中沒有找到直接從硬盤讀取索引,計算索引未命中緩存的機率:
key_cache_miss_rate =Key_reads / Key_read_requests * 100%,設置在1/1000左右較好
默認配置數值是8388600(8M),主機有4GB內存,能夠調優值爲268435456(256MB)。
5) query_cache_size
使用查詢緩衝,MySQL將查詢結果存放在緩衝區中,從此對於一樣的SELECT語句(區分大小寫),將直接從緩衝區中讀取結果。
經過檢查狀態值Qcache_*,能夠知道query_cache_size設置是否合理(上述狀態值可使用SHOW STATUS LIKE ‘Qcache%’得到)。若是Qcache_lowmem_prunes的值很是大,則代表常常出現緩衝不夠的狀況,若是Qcache_hits的值也 很是大,則代表查詢緩衝使用很是頻繁,此時須要增長緩衝大小;若是Qcache_hits的值不大,則代表你的查詢重複率很低,這種狀況下使用查詢緩衝反 而會影響效率,那麼能夠考慮不用查詢緩衝。此外,在SELECT語句中加入SQL_NO_CACHE能夠明確表示不使用查詢緩衝。
與查詢緩衝有關的參數還有query_cache_type、query_cache_limit、query_cache_min_res_unit。
query_cache_type指定是否使用查詢緩衝,能夠設置爲0、一、2,該變量是SESSION級的變量。
query_cache_limit指定單個查詢可以使用的緩衝區大小,缺省爲1M。
query_cache_min_res_unit是在4.1版本之後引入的,它指定分配緩衝區空間的最小單位,缺省爲4K。檢查狀態值 Qcache_free_blocks,若是該值很是大,則代表緩衝區中碎片不少,這就代表查詢結果都比較小,此時須要減少 query_cache_min_res_unit。
舉例以下:
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> show variables like ‘query_cache%‘;
+————————————–+————–+
| Variable_name | Value |
+————————————–+———–+
| query_cache_limit | 2097152 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 203423744 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+————————————–+—————+
查詢緩存碎片率= Qcache_free_blocks / Qcache_total_blocks * 100%
若是查詢緩存碎片率超過20%,能夠用FLUSH QUERY CACHE整理緩存碎片,或者試試減少query_cache_min_res_unit,若是你的查詢都是小數據量的話。
查詢緩存利用率= (query_cache_size – Qcache_free_memory) / query_cache_size * 100%
查詢緩存利用率在25%如下的話說明query_cache_size設置的過大,可適當減少;查詢緩存利用率在80%以上並且Qcache_lowmem_prunes > 50的話說明query_cache_size可能有點小,要不就是碎片太多。
查詢緩存命中率= (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%
示例服務器查詢緩存碎片率=20.46%,查詢緩存利用率=62.26%,查詢緩存命中率=1.94%,命中率不好,可能寫操做比較頻繁吧,並且可能有些碎片。
每一個鏈接的緩衝
6) record_buffer_size
每一個進行一個順序掃描的線程爲其掃描的每張表分配這個大小的一個緩衝區。若是你作不少順序掃描,你可能想要增長該值。
默認數值是131072(128K),可改成16773120 (16M)
7) read_rnd_buffer_size
隨機讀緩衝區大小。當按任意順序讀取行時(例如,按照排序順序),將分配一個隨機讀緩存區。進行排序查詢時,MySQL會首先掃描一遍該緩衝,以避 免磁盤搜索,提升查詢速度,若是須要排序大量數據,可適當調高該值。但MySQL會爲每一個客戶鏈接發放該緩衝空間,因此應儘可能適當設置該值,以免內存開 銷過大。
通常可設置爲16M
8) sort_buffer_size
每一個須要進行排序的線程分配該大小的一個緩衝區。增長這值加速ORDER BY或GROUP BY操做。
默認數值是2097144(2M),可改成16777208 (16M)。
9) join_buffer_size
聯合查詢操做所能使用的緩衝區大小
record_buffer_size,read_rnd_buffer_size,sort_buffer_size,join_buffer_size爲每一個線程獨佔,也就是說,若是有100個線程鏈接,則佔用爲16M*100
10) table_cache
表高速緩存的大小。每當MySQL訪問一個表時,若是在表緩衝區中還有空間,該表就被打開並放入其中,這樣能夠更快地訪問表內容。經過檢查峯值時間的狀態值Open_tables和Opened_tables,能夠決定是否須要增長table_cache的值。如 果你發現open_tables等於table_cache,而且opened_tables在不斷增加,那麼你就須要增長table_cache的值了 (上述狀態值可使用SHOW STATUS LIKE ‘Open%tables’得到)。注意,不能盲目地把table_cache設置成很大的值。若是設置得過高,可能會形成文件描述符不足,從而形成性能 不穩定或者鏈接失敗。
1G內存機器,推薦值是128-256。內存在4GB左右的服務器該參數可設置爲256M或384M。
11) max_heap_table_size
用戶能夠建立的內存表(memory table)的大小。這個值用來計算內存表的最大行數值。這個變量支持動態改變,即set @max_heap_table_size=#
這個變量和tmp_table_size一塊兒限制了內部內存表的大小。若是某個內部heap(堆積)表大小超過tmp_table_size,MySQL能夠根據須要自動將內存中的heap表改成基於硬盤的MyISAM表。
12) tmp_table_size
經過設置tmp_table_size選項來增長一張臨時表的大小,例如作高級GROUP BY操做生成的臨時表。若是調高該值,MySQL同時將增長heap表的大小,可達到提升聯接查詢速度的效果,建議儘可能優化查詢,要確保查詢過程當中生成的臨時表在內存中,避免臨時表過大致使生成基於硬盤的MyISAM表。
mysql> show global status like ‘created_tmp%‘;
+——————————–+———+
| Variable_name | Value |
+———————————-+———+
| Created_tmp_disk_tables | 21197 |
| Created_tmp_files | 58 |
| Created_tmp_tables | 1771587 |
+——————————–+———–+
每次建立臨時表,Created_tmp_tables增長,若是臨時表大小超過tmp_table_size,則是在磁盤上建立臨時 表,Created_tmp_disk_tables也增長,Created_tmp_files表示MySQL服務建立的臨時文件文件數,比較理想的配 置是:
Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%好比上面的服務器Created_tmp_disk_tables / Created_tmp_tables * 100% =1.20%,應該至關好了
默認爲16M,可調到64-256最佳,線程獨佔,太大可能內存不夠I/O堵塞
13) thread_cache_size
能夠複用的保存在中的線程的數量。若是有,新的線程從緩存中取得,當斷開鏈接的時候若是有空間,客戶的線置在緩存中。若是有不少新的線程,爲了提升性能能夠這個變量值。
經過比較 Connections和Threads_created狀態的變量,能夠看到這個變量的做用。
默認值爲110,可調優爲80。
14) thread_concurrency
推薦設置爲服務器 CPU核數的2倍,例如雙核的CPU, 那麼thread_concurrency的應該爲4;2個雙核的cpu, thread_concurrency的值應爲8。默認爲8
15) wait_timeout
指定一個請求的最大鏈接時間,對於4GB左右內存的服務器能夠設置爲5-10。
3. 配置InnoDB的幾個變量
innodb_buffer_pool_size
對於InnoDB表來講,innodb_buffer_pool_size的做用就至關於key_buffer_size對於MyISAM表的做用同樣。InnoDB使用該參數指定大小的內存來緩衝數據和索引。對於單獨的MySQL數據庫服務器,最大能夠把該值設置成物理內存的80%。
根據MySQL手冊,對於2G內存的機器,推薦值是1G(50%)。
innodb_flush_log_at_trx_commit
主要控制了innodb將log buffer中的數據寫入日誌文件並flush磁盤的時間點,取值分別爲0、一、2三個。0,表示當事務提交時,不作日誌寫入操做,而是每秒鐘將log buffer中的數據寫入日誌文件並flush磁盤一次;1,則在每秒鐘或是每次事物的提交都會引發日誌文件寫入、flush磁盤的操做,確保了事務的 ACID;設置爲2,每次事務提交引發寫入日誌文件的動做,但每秒鐘完成一次flush磁盤操做。
實際測試發現,該值對插入數據的速度影響很是大,設置爲2時插入10000條記錄只須要2秒,設置爲0時只須要1秒,而設置爲1時則須要229秒。所以,MySQL手冊也建議儘可能將插入操做合併成一個事務,這樣能夠大幅提升速度。
根據MySQL手冊,在容許丟失最近部分事務的危險的前提下,能夠把該值設爲0或2。
innodb_log_buffer_size
log緩存大小,通常爲1-8M,默認爲1M,對於較大的事務,能夠增大緩存大小。
可設置爲4M或8M。
innodb_additional_mem_pool_size
該參數指定InnoDB用來存儲數據字典和其餘內部數據結構的內存池大小。缺省值是1M。一般不用太大,只要夠用就行,應該與表結構的複雜度有關係。若是不夠用,MySQL會在錯誤日誌中寫入一條警告信息。
根據MySQL手冊,對於2G內存的機器,推薦值是20M,可適當增長。
innodb_thread_concurrency=8
推薦設置爲 2*(NumCPUs+NumDisks),默認通常爲8
MySQL 5.6相比於前代GA版本性能提高顯著,但默認緩存設置對於小型站點並不合理。經過修改my.ini文件中的performance_schema_max_table_instances參數,可以有效下降內存佔用。
如下是5.6默認的設置
performance_schema_max_table_instances 12500
table_definition_cache 1400
table_open_cache 2000
能夠調成,或者在小點均可以。
performance_schema_max_table_instances=600
table_definition_cache=400
table_open_cache=256
performance_schema_max_table_instances
The maximum number of instrumented table objects 檢測的表對象的最大數目。
table_definition_cache
The number of table definitions (from .frm files) that can be stored in the definition cache. If you use a large number of tables, you can create a large table definition cache to speed up opening of tables. The table definition cache takes less space and does not use file descriptors, unlike the normal table cache. The minimum and default values are both 400.
緩存frm文件
table_open_cache
The number of open tables for all threads. Increasing this value increases the number of file descriptors that mysqld requires.
table_open_cache 指的是緩存數據文件的描述符(Linux/Unix)相關信息
這個很重要啊,以前mount個單獨的文件,數據庫一直不成功,原來是這個在做怪啊。
chcon -R -t mysqld_db_t /home/myusqldata
mysql> show variables;
1、慢查詢
mysql> show variables like '%slow%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| log_slow_queries | ON |
| slow_launch_time | 2 |
+------------------+-------+
mysql> show global status like '%slow%';
+---------------------+-------+
| Variable_name | Value |
+---------------------+-------+
| Slow_launch_threads | 0 |
| Slow_queries | 4148 |
+---------------------+-------+
配置中打開了記錄慢查詢,執行時間超過2秒的即爲慢查詢,系統顯示有4148個慢查詢,你能夠分析慢查詢日誌,找出有問題的SQL語句,慢查詢時間不宜設置過長,不然意義不大,最好在5秒之內,若是你須要微秒級別的慢查詢,能夠考慮給MySQL打補丁:http://www.percona.com/docs/wiki/release:start,記得找對應的版本。
打開慢查詢日誌可能會對系統性能有一點點影響,若是你的MySQL是主-從結構,能夠考慮打開其中一臺從服務器的慢查詢日誌,這樣既能夠監控慢查詢,對系統性能影響又小。
2、鏈接數
常常會碰見」MySQL: ERROR 1040: Too manyconnections」的狀況,一種是訪問量確實很高,MySQL服務器抗不住,這個時候就要考慮增長從服務器分散讀壓力,另一種狀況是MySQL配置文件中max_connections值太小:
mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 256 |
+-----------------+-------+
這臺MySQL服務器最大鏈接數是256,而後查詢一下服務器響應的最大鏈接數:
mysql> show global status like 'Max_used_connections';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 245 |
+----------------------+-------+
MySQL服務器過去的最大鏈接數是245,沒有達到服務器鏈接數上限256,應該沒有出現1040錯誤,比較理想的設置是:
Max_used_connections / max_connections * 100% ≈ 85%
最大鏈接數占上限鏈接數的85%左右,若是發現比例在10%如下,MySQL服務器鏈接數上限設置的太高了。
3、Key_buffer_size
key_buffer_size是對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 | 27813678764 |
| Key_reads | 6798830 |
+------------------------+-------------+
一共有27813678764個索引讀取請求,有6798830個請求在內存中沒有找到直接從硬盤讀取索引,計算索引未命中緩存的機率:
key_cache_miss_rate = Key_reads / Key_read_requests * 100%
比 如上面的數據,key_cache_miss_rate爲0.0244%,4000個索引讀取請求才有一個直接讀硬盤,已經很BT 了,key_cache_miss_rate在0.1%如下都很好(每1000個請求有一個直接讀硬盤),若是key_cache_miss_rate在 0.01%如下的話,key_buffer_size分配的過多,能夠適當減小。
MySQL服務器還提供了key_blocks_*參數:
mysql> show global status like 'key_blocks_u%';
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_blocks_unused | 0 |
| Key_blocks_used | 413543 |
+------------------------+-------------+
Key_blocks_unused 表示未使用的緩存簇(blocks)數,Key_blocks_used表示曾經用到的最大的blocks數,好比這臺服務器,全部的緩存都用到了,要麼 增長key_buffer_size,要麼就是過渡索引了,把緩存佔滿了。比較理想的設置:
Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%
4、臨時表
mysql> show global status like 'created_tmp%';
+-------------------------+---------+
| Variable_name | Value |
+-------------------------+---------+
| Created_tmp_disk_tables | 21197 |
| Created_tmp_files | 58 |
| Created_tmp_tables | 1771587 |
+-------------------------+---------+
每次建立臨時表,Created_tmp_tables增長,若是是在磁盤上建立臨時表,Created_tmp_disk_tables也增長,Created_tmp_files表示MySQL服務建立的臨時文件文件數,比較理想的配置是:
Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%
好比上面的服務器Created_tmp_disk_tables / Created_tmp_tables * 100% = 1.20%,應該至關好了。咱們再看一下MySQL服務器對臨時表的配置:
mysql> show variables where Variable_name in ('tmp_table_size', 'max_heap_table_size');
+---------------------+-----------+
| Variable_name | Value |
+---------------------+-----------+
| max_heap_table_size | 268435456 |
| tmp_table_size | 536870912 |
+---------------------+-----------+
只有256MB如下的臨時表才能所有放內存,超過的就會用到硬盤臨時表。
5、Open Table狀況
mysql> show global status like 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 919 |
| Opened_tables | 1951 |
+---------------+-------+
Open_tables 表示打開表的數量,Opened_tables表示打開過的表數量,若是Opened_tables數量過大,說明配置中 table_cache(5.1.3以後這個值叫作table_open_cache)值可能過小,咱們查詢一下服務器table_cache值:
mysql> show variables like 'table_cache';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| table_cache | 2048 |
+---------------+-------+
比較合適的值爲:
Open_tables / Opened_tables * 100% >= 85%
Open_tables / table_cache * 100% <= 95%
6、進程使用狀況
mysql> show global status like 'Thread%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 46 |
| Threads_connected | 2 |
| Threads_created | 570 |
| Threads_running | 1 |
+-------------------+-------+
如 果咱們在MySQL服務器配置文件中設置了thread_cache_size,當客戶端斷開以後,服務器處理此客戶的線程將會緩存起來以響應下一個客戶 而不是銷燬(前提是緩存數未達上限)。Threads_created表示建立過的線程數,若是發現Threads_created值過大的話,代表 MySQL服務器一直在建立線程,這也是比較耗資源,能夠適當增長配置文件中thread_cache_size值,查詢服務器 thread_cache_size配置:
mysql> show variables like 'thread_cache_size';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| thread_cache_size | 64 |
+-------------------+-------+
示例中的服務器仍是挺健康的。
7、查詢緩存(query cache)
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:每次查詢在緩存中命中時就增大
Qcache_inserts:每次插入一個查詢時就增大。命中次數除以插入次數就是不中比率。
Qcache_lowmem_prunes: 緩存出現內存不足而且必需要進行清理以便爲更多查詢提供空間的次數。這個數字最好長時間來看;若是這個數字在不斷增加,就表示可能碎片很是嚴重,或者內存 不多。(上面的 free_blocks和free_memory能夠告訴您屬於哪一種狀況)
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 | 2097152 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 203423744 |
| 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_invalidate:當有其餘客戶端正在對MyISAM表進行寫操做時,若是查詢在query cache中,是否返回cache結果仍是等寫操做完成再讀表獲取結果。
query_cache_min_res_unit的配置是一柄」雙刃劍」,默認是4KB,設置值大對大數據查詢有好處,但若是你的查詢都是小數據查詢,就容易形成內存碎片和浪費。
查詢緩存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
若是查詢緩存碎片率超過20%,能夠用FLUSH QUERY CACHE整理緩存碎片,或者試試減少query_cache_min_res_unit,若是你的查詢都是小數據量的話。
查詢緩存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%
查詢緩存利用率在25%如下的話說明query_cache_size設置的過大,可適當減少;查詢緩存利用率在80%以上並且Qcache_lowmem_prunes > 50的話說明query_cache_size可能有點小,要不就是碎片太多。
查詢緩存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%
示例服務器 查詢緩存碎片率 = 20.46%,查詢緩存利用率 = 62.26%,查詢緩存命中率 = 1.94%,命中率不好,可能寫操做比較頻繁吧,並且可能有些碎片。
8、排序使用狀況
mysql> show global status like 'sort%';
+-------------------+------------+
| Variable_name | Value |
+-------------------+------------+
| Sort_merge_passes | 29 |
| Sort_range | 37432840 |
| Sort_rows | 9178691532 |
| Sort_scan | 1860569 |
+-------------------+------------+
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 並不必定能提升速度,
另外,增長read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值對排序的操做也有一點的好處,
9、文件打開數(open_files)
mysql> show global status like 'open_files';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files | 1410 |
+---------------+-------+
mysql> show variables like 'open_files_limit';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 4590 |
+------------------+-------+
比較合適的設置:Open_files / open_files_limit * 100% <= 75%
10、表鎖狀況
mysql> show global status like 'table_locks%';
+-----------------------+-----------+
| Variable_name | Value |
+-----------------------+-----------+
| Table_locks_immediate | 490206328 |
| Table_locks_waited | 2084912 |
+-----------------------+-----------+
Table_locks_immediate 表示當即釋放表鎖數,Table_locks_waited表示須要等待的表鎖數,若是Table_locks_immediate / Table_locks_waited >5000,最好採用InnoDB引擎,由於InnoDB是行鎖而MyISAM是表鎖,對於高併發寫入的應用InnoDB效果會好些。示例中的服務 器Table_locks_immediate / Table_locks_waited = 235,MyISAM就足夠了。
11、表掃描狀況mysql> show global status like 'handler_read%';+-----------------------+-------------+| Variable_name | Value |+-----------------------+-------------+| Handler_read_first | 5803750 || Handler_read_key | 6049319850 || Handler_read_next | 94440908210 || Handler_read_prev | 34822001724 || Handler_read_rnd | 405482605 || Handler_read_rnd_next | 18912877839 |+-----------------------+-------------+各字段解釋參見,調出服務器完成的查詢請求次數:mysql> show global status like 'com_select';+---------------+-----------+| Variable_name | Value |+---------------+-----------+| Com_select | 222693559 |+---------------+-----------+計算表掃描率:表掃描率 = Handler_read_rnd_next / Com_select若是表掃描率超過4000,說明進行了太多表掃描,頗有可能索引沒有建好,增長read_buffer_size值會有一些好處,但最好不要超過8MB。要查看死鎖,你要show engine innodb status\G;在MySQL5.6版本,在my.cnf配置文件裏,加入innodb_print_all_deadlocks = 1就能夠把死鎖信息打印到錯誤日誌裏