https://blog.csdn.net/steven_liwen/article/details/53188411
運維角度mysql優(yōu)化:https://www.cnblogs.com/shenjianyu/p/6405524.html
1、目的:
通過根據(jù)服務器目前狀況,修改MySQL的系統(tǒng)參數(shù),達到合理利用服務器現(xiàn)有資源,最大合理的提高MySQL性能。
32G內存、4個CPU,每個CPU?8核。
????MySQL目前安裝,用的是MySQL默認的最大支持配置。拷貝的是my-huge.cnf.編碼已修改為UTF-8.具體修改及安裝MySQL,可以參考<<Linux系統(tǒng)上安裝MySQL?5.5>>幫助文檔。
打開MySQL配置文件my.cnf
vi??/etc/my.cnf
4.1.1修改back_log參數(shù)值:由默認的50修改為500.(每個連接256kb,占用:125M)
??????????back_log=500
????back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。也就是說,如果MySql的連接數(shù)據(jù)達到max_connections時,新來的請求將會被存在堆棧中,以等待某一連接釋放資源,該堆棧的數(shù)量即back_log,如果等待連接的數(shù)量超過back_log,將不被授予連接資源。將會報:unauthenticated?user?|?xxx.xxx.xxx.xxx?|?NULL?|?Connect?|?NULL?|?login?|?NULL?的待連接進程時.
back_log值不能超過TCP/IP連接的偵聽隊列的大小。若超過則無效,查看當前系統(tǒng)的TCP/IP連接的偵聽隊列的大小命令:cat?/proc/sys/net/ipv4/tcp_max_syn_backlog目前系統(tǒng)為1024。對于Linux系統(tǒng)推薦設置為小于512的整數(shù)。
修改系統(tǒng)內核參數(shù),)http://www.51testing.com/html/64/n-810764.html
查看mysql?當前系統(tǒng)默認back_log值,命令:
show?variables?like?'back_log';?查看當前數(shù)量
4.1.2修改wait_timeout參數(shù)值,由默認的8小時,修改為30分鐘。(本次不用)
??????????wait_timeout=1800(單位為妙)
我對wait-timeout這個參數(shù)的理解:MySQL客戶端的數(shù)據(jù)庫連接閑置最大時間值。
說得比較通俗一點,就是當你的MySQL連接閑置超過一定時間后將會被強行關閉。MySQL默認的wait-timeout??值為8個小時,可以通過命令show?variables?like?'wait_timeout'查看結果值;。
設置這個值是非常有意義的,比如你的網(wǎng)站有大量的MySQL鏈接請求(每個MySQL連接都是要內存資源開銷的?),由于你的程序的原因有大量的連接請求空閑啥事也不干,白白占用內存資源,或者導致MySQL超過最大連接數(shù)從來無法新建連接導致“Too?many?connections”的錯誤。在設置之前你可以查看一下你的MYSQL的狀態(tài)(可用show?processlist),如果經(jīng)常發(fā)現(xiàn)MYSQL中有大量的Sleep進程,則需要?修改wait-timeout值了。
interactive_timeout:服務器關閉交互式連接前等待活動的秒數(shù)。交互式客戶端定義為在mysql_real_connect()中使用CLIENT_INTERACTIVE選項的客戶端。
wait_timeout:服務器關閉非交互連接之前等待活動的秒數(shù)。在線程啟動時,根據(jù)全局wait_timeout值或全局?interactive_timeout值初始化會話wait_timeout值,取決于客戶端類型(由mysql_real_connect()的連接選項CLIENT_INTERACTIVE定義).
這兩個參數(shù)必須配合使用。否則單獨設置wait_timeout無效
4.1.3修改max_connections參數(shù)值,由默認的151,修改為3000(750M)。
????max_connections=3000
max_connections是指MySql的最大連接數(shù),如果服務器的并發(fā)連接請求量比較大,建議調高此值,以增加并行連接數(shù)量,當然這建立在機器能支撐的情況下,因為如果連接數(shù)越多,介于MySql會為每個連接提供連接緩沖區(qū),就會開銷越多的內存,所以要適當調整該值,不能盲目提高設值。可以過'conn%'通配符查看當前狀態(tài)的連接數(shù)量,以定奪該值的大小。
MySQL服務器允許的最大連接數(shù)16384;
查看系統(tǒng)當前最大連接數(shù):
show?variables?like?'max_connections';
4.1..4修改max_user_connections值,由默認的0,修改為800
?????max_user_connections=800
?max_user_connections是指每個數(shù)據(jù)庫用戶的最大連接
針對某一個賬號的所有客戶端并行連接到MYSQL服務的最大并行連接數(shù)。簡單說是指同一個賬號能夠同時連接到mysql服務的最大連接數(shù)。設置為0表示不限制。
目前默認值為:0不受限制。
這兒順便介紹下Max_used_connections:它是指從這次mysql服務啟動到現(xiàn)在,同一時刻并行連接數(shù)的最大值。它不是指當前的連接情況,而是一個比較值。如果在過去某一個時刻,MYSQL服務同時有1000個請求連接過來,而之后再也沒有出現(xiàn)這么大的并發(fā)請求時,則Max_used_connections=1000.請注意與show?variables?里的max_user_connections的區(qū)別。默認為0表示無限大。
查看max_user_connections值
show?variables?like?'max_user_connections';
4.1.5修改thread_concurrency值,由目前默認的8,修改為64
?????thread_concurrency=64
thread_concurrency的值的正確與否,對mysql的性能影響很大,在多個cpu(或多核)的情況下,錯誤設置了thread_concurrency的值,會導致mysql不能充分利用多cpu(或多核),出現(xiàn)同一時刻只能一個cpu(或核)在工作的情況。
thread_concurrency應設為CPU核數(shù)的2倍.比如有一個雙核的CPU,那thread_concurrency??的應該為4;?2個雙核的cpu,thread_concurrency的值應為8.
比如:根據(jù)上面介紹我們目前系統(tǒng)的配置,可知道為4個CPU,每個CPU為8核,按照上面的計算規(guī)則,這兒應為:4*8*2=64
查看系統(tǒng)當前thread_concurrency默認配置命令:
?show?variables?like?'thread_concurrency';
4.1.6添加skip-name-resolve,默認被注釋掉,沒有該參數(shù)。
skip-name-resolve
skip-name-resolve:禁止MySQL對外部連接進行DNS解析,使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意,如果開啟該選項,則所有遠程主機連接授權都要使用IP地址方式,否則MySQL將無法正常處理連接請求!
4.1.7?skip-networking,默認被注釋掉。沒有該參數(shù)。(本次無用)
?skip-networking建議被注釋掉,不要開啟
開啟該選項可以徹底關閉MySQL的TCP/IP連接方式,如果WEB服務器是以遠程連接的方式訪問MySQL數(shù)據(jù)庫服務器則不要開啟該選項!否則將無法正常連接!
4.1.8??default-storage-engine(設置MySQL的默認存儲引擎)
default-storage-engine=?InnoDB(設置InnoDB類型,另外還可以設置MyISAM類型)
設置創(chuàng)建數(shù)據(jù)庫及表默認存儲類型
show?table?status?like?‘tablename’顯示表的當前存儲狀態(tài)值
查看MySQL有哪些存儲狀態(tài)及默認存儲狀態(tài)
?show?engines;
創(chuàng)建表并指定存儲類型
CREATE?TABLE?mytable?(id?int,?title?char(20))?ENGINE?=?INNODB;
修改表存儲類型:
??Alter?table?tableName?engine?=engineName
備注:設置完后把以下幾個開啟:
#?Uncomment?the?following?if?you?are?using?InnoDB?tables
innodb_data_home_dir?=?/var/lib/mysql
#innodb_data_file_path?=?ibdata1:1024M;ibdata2:10M:autoextend(要注釋掉,否則會創(chuàng)建一個新的把原來的替換的。)
innodb_log_group_home_dir?=?/var/lib/mysql
#?You?can?set?.._buffer_pool_size?up?to?50?-?80?%
#?of?RAM?but?beware?of?setting?memory?usage?too?high
innodb_buffer_pool_size?=?1000M
innodb_additional_mem_pool_size?=?20M
#?Set?.._log_file_size?to?25?%?of?buffer?pool?size
innodb_log_file_size?=?500M
innodb_log_buffer_size?=?20M
innodb_flush_log_at_trx_commit?=?0
innodb_lock_wait_timeout?=?50
設置完后一定記得把MySQL安裝目錄地址(我們目前是默認安裝所以地址/var/lib/mysql/)下的ib_logfile0和ib_logfile1刪除掉。否則重啟MySQL起動失敗。
數(shù)據(jù)庫屬于IO密集型的應用程序,其主職責就是數(shù)據(jù)的管理及存儲工作。而我們知道,從內存中讀取一個數(shù)據(jù)庫的時間是微秒級別,而從一塊普通硬盤上讀取一個IO是在毫秒級別,二者相差3個數(shù)量級。所以,要優(yōu)化數(shù)據(jù)庫,首先第一步需要優(yōu)化的就是IO,盡可能將磁盤IO轉化為內存IO。本文先從MySQL數(shù)據(jù)庫IO相關參數(shù)(緩存參數(shù))的角度來看看可以通過哪些參數(shù)進行IO優(yōu)化
啟動MySQL時就要分配并且總是存在的全局緩存。目前有:key_buffer_size(默認值:402653184,即384M)、innodb_buffer_pool_size(默認值:134217728即:128M)、innodb_additional_mem_pool_size(默認值:8388608即:8M)、innodb_log_buffer_size(默認值:8388608即:8M)、query_cache_size(默認值:33554432即:32M)等五個。總共:560M.
這些變量值都可以通過命令如:show?variables?like?'變量名';查看到。
4.2.1.1:key_buffer_size,本系統(tǒng)目前為384M,可修改為400M
????key_buffer_size=400M
key_buffer_size是用于索引塊的緩沖區(qū)大小,增加它可得到更好處理的索引(對所有讀和多重寫),對MyISAM(MySQL表存儲的一種類型,可以百度等查看詳情)表性能影響最大的一個參數(shù)。如果你使它太大,系統(tǒng)將開始換頁并且真的變慢了。嚴格說是它決定了數(shù)據(jù)庫索引處理的速度,尤其是索引讀的速度。對于內存在4GB左右的服務器該參數(shù)可設置為256M或384M.
怎么才能知道key_buffer_size的設置是否合理呢,一般可以檢查狀態(tài)值Key_read_requests和Key_reads,比例key_reads?/?key_read_requests應該盡可能的低,比如1:100,1:1000,1:10000。其值可以用以下命令查得:show?status?like?'key_read%';
比如查看系統(tǒng)當前key_read和key_read_request值為:
+-------------------+-------+
|?Variable_name?????|?Value?|
+-------------------+-------+
|?Key_read_requests?|?28535?|
|?Key_reads?????????|?269???|
+-------------------+-------+
可知道有28535個請求,有269個請求在內存中沒有找到直接從硬盤讀取索引.
未命中緩存的概率為:0.94%=269/28535*100%.一般未命中概率在0.1之下比較好。目前已遠遠大于0.1,證明效果不好。若命中率在0.01以下,則建議適當?shù)男薷膋ey_buffer_size值。
http://dbahacker.com/mysql/innodb-myisam-compare(InnoDB與MyISAM的六大區(qū)別)
http://kb.cnblogs.com/page/99810/(查看存儲引擎介紹)
MyISAM、InnoDB、MyISAM?Merge引擎、InnoDB、memory(heap)、archive
4.2.1.2:innodb_buffer_pool_size(默認128M)
innodb_buffer_pool_size=1024M(1G)
innodb_buffer_pool_size:主要針對InnoDB表性能影響最大的一個參數(shù)。功能與Key_buffer_size一樣。InnoDB占用的內存,除innodb_buffer_pool_size用于存儲頁面緩存數(shù)據(jù)外,另外正常情況下還有大約8%的開銷,主要用在每個緩存頁幀的描述、adaptive?hash等數(shù)據(jù)結構,如果不是安全關閉,啟動時還要恢復的話,還要另開大約12%的內存用于恢復,兩者相加就有差不多21%的開銷。假設:12G的innodb_buffer_pool_size,最多的時候InnoDB就可能占用到14.5G的內存。若系統(tǒng)只有16G,而且只運行MySQL,且MySQL只用InnoDB,
那么為MySQL開12G,是最大限度地利用內存了。
另外InnoDB和?MyISAM?存儲引擎不同,?MyISAM?的?key_buffer_size?只能緩存索引鍵,而?innodb_buffer_pool_size?卻可以緩存數(shù)據(jù)塊和索引鍵。適當?shù)脑黾舆@個參數(shù)的大小,可以有效的減少?InnoDB?類型的表的磁盤?I/O?。
當我們操作一個InnoDB表的時候,返回的所有數(shù)據(jù)或者去數(shù)據(jù)過程中用到的任何一個索引塊,都會在這個內存區(qū)域中走一遭。
可以通過(Innodb_buffer_pool_read_requests?–?Innodb_buffer_pool_reads)?/?Innodb_buffer_pool_read_requests?*?100%計算緩存命中率,并根據(jù)命中率來調整innodb_buffer_pool_size參數(shù)大小進行優(yōu)化。值可以用以下命令查得:show?status?like?'Innodb_buffer_pool_read%';
比如查看當前系統(tǒng)中系統(tǒng)中
|?Innodb_buffer_pool_read_requests??????|?1283826?|
|?Innodb_buffer_pool_reads??????????????|?519?????|
+---------------------------------------+---------+
其命中率99.959%=(1283826-519)/1283826*100%命中率越高越好。
4.2.1.3:innodb_additional_mem_pool_size(默認8M)
??innodb_additional_mem_pool_size=20M
innodb_additional_mem_pool_size設置了InnoDB存儲引擎用來存放數(shù)據(jù)字典信息以及一些內部數(shù)據(jù)結構的內存空間大小,所以當我們一個MySQL?Instance中的數(shù)據(jù)庫對象非常多的時候,是需要適當調整該參數(shù)的大小以確保所有數(shù)據(jù)都能存放在內存中提高訪問效率的。
這個參數(shù)大小是否足夠還是比較容易知道的,因為當過小的時候,MySQL會記錄Warning信息到數(shù)據(jù)庫的error?log中,這時候你就知道該調整這個參數(shù)大小了。
查看當前系統(tǒng)mysql的error日志cat??/var/lib/mysql/機器名.error發(fā)現(xiàn)有很多waring警告。所以要調大為20M.
根據(jù)MySQL手冊,對于2G內存的機器,推薦值是20M。
????32G內存的?100M
4.2.1.4:innodb_log_buffer_size(默認8M)
innodb_log_buffer_size=20M
innodb_log_buffer_size??這是InnoDB存儲引擎的事務日志所使用的緩沖區(qū)。類似于Binlog?Buffer,InnoDB在寫事務日志的時候,為了提高性能,也是先將信息寫入Innofb?Log?Buffer中,當滿足innodb_flush_log_trx_commit參數(shù)所設置的相應條件(或者日志緩沖區(qū)寫滿)之后,才會將日志寫到文件?(或者同步到磁盤)中。可以通過innodb_log_buffer_size?參數(shù)設置其可以使用的最大內存空間。
InnoDB?將日志寫入日志磁盤文件前的緩沖大小。理想值為?1M?至?8M。大的日志緩沖允許事務運行時不需要將日志保存入磁盤而只到事務被提交(commit)。?因此,如果有大的事務處理,設置大的日志緩沖可以減少磁盤I/O。?在my.cnf中以數(shù)字格式設置。
默認是8MB,系的如頻繁的系統(tǒng)可適當增大至4MB~8MB。當然如上面介紹所說,這個參數(shù)實際上還和另外的flush參數(shù)相關。一般來說不建議超過32MB
注:innodb_flush_log_trx_commit參數(shù)對InnoDB?Log的寫入性能有非常關鍵的影響,默認值為1。該參數(shù)可以設置為0,1,2,解釋如下:
0:log?buffer中的數(shù)據(jù)將以每秒一次的頻率寫入到log?file中,且同時會進行文件系統(tǒng)到磁盤的同步操作,但是每個事務的commit并不會觸發(fā)任何log?buffer?到log?file的刷新或者文件系統(tǒng)到磁盤的刷新操作;
1:在每次事務提交的時候將log?buffer?中的數(shù)據(jù)都會寫入到log?file,同時也會觸發(fā)文件系統(tǒng)到磁盤的同步;
2:事務提交會觸發(fā)log?buffer到log?file的刷新,但并不會觸發(fā)磁盤文件系統(tǒng)到磁盤的同步。此外,每秒會有一次文件系統(tǒng)到磁盤同步操作。
實際測試發(fā)現(xiàn),該值對插入數(shù)據(jù)的速度影響非常大,設置為2時插入10000條記錄只需要2秒,設置為0時只需要1秒,而設置為1時則需要229秒。因此,MySQL手冊也建議盡量將插入操作合并成一個事務,這樣可以大幅提高速度。根據(jù)MySQL手冊,在存在丟失最近部分事務的危險的前提下,可以把該值設為0。
4.5.1.5:query_cache_size(默認32M)
query_cache_size=40M
query_cache_size:主要用來緩存MySQL中的ResultSet,也就是一條SQL語句執(zhí)行的結果集,所以僅僅只能針對select語句。當我們打開了Query?Cache功能,MySQL在接受到一條select語句的請求后,如果該語句滿足Query?Cache的要求(未顯式說明不允許使用Query?Cache,或者已經(jīng)顯式申明需要使用Query?Cache),MySQL會直接根據(jù)預先設定好的HASH算法將接受到的select語句以字符串方式進行hash,然后到Query?Cache中直接查找是否已經(jīng)緩存。也就是說,如果已經(jīng)在緩存中,該select請求就會直接將數(shù)據(jù)返回,從而省略了后面所有的步驟(如SQL語句的解析,優(yōu)化器優(yōu)化以及向存儲引擎請求數(shù)據(jù)等),極大的提高性能。根據(jù)MySQL用戶手冊,使用查詢緩沖最多可以達到238%的效率。
當然,Query?Cache也有一個致命的缺陷,那就是當某個表的數(shù)據(jù)有任何任何變化,都會導致所有引用了該表的select語句在Query?Cache中的緩存數(shù)據(jù)失效。所以,當我們的數(shù)據(jù)變化非常頻繁的情況下,使用Query?Cache可能會得不償失
Query?Cache的使用需要多個參數(shù)配合,其中最為關鍵的是query_cache_size和query_cache_type,前者設置用于緩存ResultSet的內存大小,后者設置在何場景下使用Query?Cache。在以往的經(jīng)驗來看,如果不是用來緩存基本不變的數(shù)據(jù)的MySQL數(shù)據(jù)庫,query_cache_size一般256MB是一個比較合適的大小。當然,這可以通過計算Query?Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))來進行調整。query_cache_type可以設置為0(OFF),1(ON)或者2(DEMOND),分別表示完全不使用query?cache,除顯式要求不使用query?cache(使用sql_no_cache)之外的所有的select都使用query?cache,只有顯示要求才使用query?cache(使用sql_cache)。如果Qcache_lowmem_prunes的值非常大,則表明經(jīng)常出現(xiàn)緩沖.如果Qcache_hits的值也非常大,則表明查詢緩沖使用非常頻繁,此時需要增加緩沖大小;
根據(jù)命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))進行調整,一般不建議太大,256MB可能已經(jīng)差不多了,大型的配置型靜態(tài)數(shù)據(jù)可適當調大.
可以通過命令:show?status?like?'Qcache_%';查看目前系統(tǒng)Query?catch使用大小
|?Qcache_hits?????????????|?1892463??|
|?Qcache_inserts??????????|?35627??
命中率98.17%=1892463/(1892463?+35627?)*100
除了全局緩沖,MySql還會為每個連接發(fā)放連接緩沖。個連接到MySQL服務器的線程都需要有自己的緩沖。大概需要立刻分配256K,甚至在線程空閑時,它們使用默認的線程堆棧,網(wǎng)絡緩存等。事務開始之后,則需要增加更多的空間。運行較小的查詢可能僅給指定的線程增加少量的內存消耗,然而如果對數(shù)據(jù)表做復雜的操作例如掃描、排序或者需要臨時表,則需分配大約read_buffer_size,
sort_buffer_size,read_rnd_buffer_size,tmp_table_size大小的內存空間.不過它們只是在需要的時候才分配,并且在那些操作做完之后就釋放了。有的是立刻分配成單獨的組塊。tmp_table_size可能高達MySQL所能分配給這個操作的最大內存空間了
。注意,這里需要考慮的不只有一點——可能會分配多個同一種類型的緩存,例如用來處理子查詢。一些特殊的查詢的內存使用量可能更大——如果在MyISAM表上做成批的插入
時需要分配bulk_insert_buffer_size大小的內存;執(zhí)行ALTER?TABLE,OPTIMIZE?TABLE,REPAIR?TABLE命令時需要分配myisam_sort_buffer_size大小的內存。
4.2.2.1:read_buffer_size(默認值:2097144即2M)
read_buffer_size=4M
read_buffer_size是MySql讀入緩沖區(qū)大小。對表進行順序掃描的請求將分配一個讀入緩沖區(qū),MySql會為它分配一段內存緩沖區(qū)。read_buffer_size變量控制這一
緩沖區(qū)的大小。如果對表的順序掃描請求非常頻繁,并且你認為頻繁掃描進行得太慢,可以通過增加該變量值以及內存緩沖區(qū)大小提高其性能.
4.2.2.2:sort_buffer_size(默認值:2097144即2M)
sort_buffer_size=4M
sort_buffer_size是MySql執(zhí)行排序使用的緩沖大小。如果想要增加ORDER?BY的速度,首先看是否可以讓MySQL使用索引而不是額外的排序階段。如果不能,可以嘗試增加sort_buffer_size變量的大小
4.2.2.3:??read_rnd_buffer_size(默認值:8388608即8M)
read_rnd_buffer_size=8M
read_rnd_buffer_size是MySql的隨機讀緩沖區(qū)大小。當按任意順序讀取行時(例如,按照排序順序),將分配一個隨機讀緩存區(qū)。進行排序查詢時,MySql會首先掃描一遍該緩沖,以避免磁盤搜索,提高查詢速度,如果需要排序大量數(shù)據(jù),可適當調高該值。但MySql會為每個客戶連接發(fā)放該緩沖空間,所以應盡量適當設置該值,以避免內存開
銷過大。
4.2.2.4:??tmp_table_size(默認值:8388608即:16M)
tmp_table_size=16M
tmp_table_size是MySql的heap(堆積)表緩沖大小。所有聯(lián)合在一個DML指令內完成,并且大多數(shù)聯(lián)合甚至可以不用臨時表即可以完成。大多數(shù)臨時表是基于內
存的(HEAP)表。具有大的記錄長度的臨時表(所有列的長度的和)或包含BLOB列的表存儲在硬盤上。如果某個內部heap(堆積)表大小超過tmp_table_size,MySQL可以根據(jù)需要自
動將內存中的heap表改為基于硬盤的MyISAM表。還可以通過設置tmp_table_size選項來增加臨時表的大小。也就是說,如果調高該值,MySql同時將增加heap表的大小,可達到提高
聯(lián)接查詢速度的效果。
4.2.2.5:record_buffer:(默認值:)
record_buffer每個進行一個順序掃描的線程為其掃描的每張表分配這個大小的一個緩沖區(qū)。如果你做很多順序掃描,你可能想要增加該值。默認數(shù)值是131072
(128K)
4.2.3.1:table_cache(默認值:512)
TABLE_CACHE(5.1.3及以后版本又名TABLE_OPEN_CACHE)
table_cache指定表高速緩存的大小。每當MySQL訪問一個表時,如果在表緩沖區(qū)中還有空間,該表就被打開并放入其中,這樣可以更快地訪問表內容。通過檢查峰值時間的狀態(tài)值Open_tables和Opened_tables,可以決定是否需要增加table_cache的值。如果你發(fā)現(xiàn)open_tables等于table_cache,并且opened_tables在不斷增長,那么你就需要增加table_cache的值了(上述狀態(tài)值可以使用SHOW?STATUS?LIKE?‘Open%tables’獲得)。注意,不能盲目地把table_cache設置成很大的值。如果設置得太高,可能會造成文件描述符不足,從而造成性能不穩(wěn)定或者連接失敗。
SHOW?STATUS?LIKE?'Open%tables';
+---------------+-------+
|?Variable_name?|?Value?|
+---------------+-------+
|?Open_tables???|?356???|
|?Opened_tables?|?0?????|
+---------------+-------+
2?rows?in?set?(0.00?sec)
open_tables表示當前打開的表緩存數(shù),如果執(zhí)行flush?tables操作,則此系統(tǒng)會關閉一些當前沒有使用的表緩存而使得此狀態(tài)值減小;
opend_tables表示曾經(jīng)打開的表緩存數(shù),會一直進行累加,如果執(zhí)行flush?tables操作,值不會減小。
在mysql默認安裝情況下,table_cache的值在2G內存以下的機器中的值默認時256到512,如果機器有4G內存,則默認這個值?是2048,但這決意味著機器內存越大,這個值應該越大,因為table_cache加大后,使得mysql對SQL響應的速度更快了,不可避免的會產(chǎn)生?更多的死鎖(dead?lock),這樣反而使得數(shù)據(jù)庫整個一套操作慢了下來,嚴重影響性能。所以平時維護中還是要根據(jù)庫的實際情況去作出判斷,找到最適合你維護的庫的?table_cache值。
由于MySQL是多線程的機制,為了提高性能,每個線程都是獨自打開自己需要的表的文件描?述符,而不是通過共享已經(jīng)打開的.針對不同存儲引擎處理的方法當然也不一樣
在myisam表引擎中,數(shù)據(jù)文件的描述符?(descriptor)是不共享的,但是索引文件的描述符卻是所有線程共享的.Innodb中和使用表空間類型有關,假如是共享表空間那么實際就一個數(shù)?據(jù)文件,當然占用的數(shù)據(jù)文件描述符就會比獨立表空間少.
mysql手冊上給的建議大小?是:table_cache=max_connections*n
n表示查詢語句中最大表數(shù),?還需要為臨時表和文件保留一些額外的文件描述符。
這個數(shù)據(jù)遭到很多質疑,table_cache夠用就好,檢查?Opened_tables值,如果這個值很大,或增長很快那么你就得考慮加大table_cache了.
??table_cache:所有線程打開的表的數(shù)目。增大該值可以增加mysqld需要的文件描述符的數(shù)量。默認值是64.
4.2.3.2?thread_cache_size?(服務器線程緩存)
thread_cache_size=64
默認的thread_cache_size=8,但是看到好多配置的樣例里的值一般是32,64,甚至是128,感覺這個參數(shù)對優(yōu)化應該有幫助,于是查了下:
根據(jù)調查發(fā)現(xiàn)以上服務器線程緩存thread_cache_size沒有進行設置,或者設置過小,這個值表示可以重新利用保存在緩存中線程的數(shù)量,當斷開連接時如果緩存中還有空間,那么客戶端的線程將被放到緩存中,如果線程重新被請求,那么請求將從緩存中讀取,如果緩存中是空的或者是新的請求,那么這個線程將被重新創(chuàng)建,如果有很多新的線程,增加這個值可以改善系統(tǒng)性能.通過比較Connections和Threads_created狀態(tài)的變量,可以看到這個變量的作用。(–>表示要調整的值)根據(jù)物理內存設置規(guī)則如下:
1G?—>?8
2G?—>?16
3G?—>?32?????>3G?—>?64
mysql>?show?status?like?'thread%';
+——————-+——-+
|?Variable_name?????|?Value?|
+——————-+——-+
|?Threads_cached????|?0?????|??<—當前被緩存的空閑線程的數(shù)量
|?Threads_connected?|?1?????|??<—正在使用(處于連接狀態(tài))的線程
|?Threads_created???|?1498??|??<—服務啟動以來,創(chuàng)建了多少個線程
|?Threads_running???|?1?????|??<—正在忙的線程(正在查詢數(shù)據(jù),傳輸數(shù)據(jù)等等操作)
+——————-+——-+
查看開機起來數(shù)據(jù)庫被連接了多少次?
mysql>?show?status?like?'%connection%';
+———————-+——-+
|?Variable_name????????|?Value?|
+———————-+——-+
|?Connections??????????|?1504??|??????????–>服務啟動以來,歷史連接數(shù)
|?Max_used_connections?|?2?????|
+———————-+——-+
通過連接線程池的命中率來判斷設置值是否合適?命中率超過90%以上,設定合理。
?(Connections?-??Threads_created)?/?Connections?*?100?%
1、MySQL參數(shù)優(yōu)化
1:MySQL 默認的最大連接數(shù)為 100,可以在 mysql 客戶端使用以下命令查看
mysql> show variables like 'max_connections';
2:查看當前訪問Mysql的線程
mysql> show processlist;
3:設置最大連接數(shù)
mysql>set globle max_connections = 5000;
最大可設置16384,超過沒用
4:查看當前被使用的connections
mysql>show globle status like 'max_user_connections'
1、磁盤尋道能力(磁盤I/O),我們現(xiàn)在用的都是SAS15000轉的硬盤,用6快這樣的硬盤作RAID1+0。MySQL每一秒鐘都在進行大量、復雜的查詢操作,對磁盤的讀寫量可想而知,所以,通常認為磁盤I/O是約制MySQL性能的最大因素之一。對于日均訪問量在100萬PV以上的論壇(Discuz)、博客(Wordpress),如果性能不好,造成的直接后果就是MySQL的性能會非常低下!解決這一制約因素可以考慮解決訪問是:使用RAID1+0磁盤陣列,注意不要嘗試RAID5,MySQL在PAID5磁盤陣列上的效率不會像你期待的那樣快,如果資金允許,可以選擇固態(tài)硬盤SSD來替代SAS硬盤做RAID1+0。
3、對于一臺使用MySQL的Database Server來說,建議服務器的內存不要小于2GB,推薦使用4GB以上的物理內存,不過內存對于現(xiàn)在的服務器而言可以說是一個可以忽略的問題,如果是高端服務器,基本上內存都超過了32GB,我們的數(shù)據(jù)流服務器都是32GB內存。
MySQL配置文件優(yōu)化
[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服務啟動的參數(shù),它涉及的方面很多,其中有MySQL的目錄和文件,通信、網(wǎng)絡、信息安全,內存管理、優(yōu)化、查詢緩存區(qū),還有MySQL日志設置等。
user = mysql?#mysql_safe腳本使用MySQL運行用戶(編譯時–user=mysql指定),推薦使用mysql用戶。
port = 3306?#MySQL服務運行時的端口號。建議更改默認端口,默認容易遭受攻擊。
socket = /data/3306/mysql.sock?#socket文件是在Linux/Unix環(huán)境下特有的,用戶在Linux/Unix環(huán)境下客戶端連接可以不通過TCP/IP網(wǎng)絡而直接使用unix socket連接MySQL。
basedir = /application/mysql?#mysql程序所存放路徑,常用于存放mysql啟動、配置文件、日志等
datadir = /data/3306/data?#MySQL數(shù)據(jù)存放文件(極其重要)
character-set-server = utf8?#數(shù)據(jù)庫和數(shù)據(jù)庫表的默認字符集。(推薦utf8,以免導致亂碼)
log-error=/data/3306/mysql_xuliangwei.err?#mysql錯誤日志存放路徑及名稱(啟動出現(xiàn)錯誤一定要看錯誤日志,百分之百都能通過錯誤日志排插解決。)
pid-file=/data/3306/mysql_xuliangwei.pid?#MySQL_pid文件記錄的是當前mysqld進程的pid,pid亦即?ProcessID。
skip-locking?#避免MySQL的外部鎖定,減少出錯幾率,增強穩(wěn)定性。
skip-name-resolv?#禁止MySQL對外部連接進行DNS解析,使用這一選項可以消除MySQL進行DNS解析的時候。但是需要注意的是,如果開啟該選項,則所有遠程主機連接授權都要使用IP地址方式了,否則MySQL將無法正常處理連接請求!
skip-networking?#開啟該選項可以徹底關閉MySQL的TCP/IP連接方式,如果Web服務器是以遠程連接的方式訪問MySQL數(shù)據(jù)庫服務器的,則不要開啟該選項,否則無法正常連接!
open_files_limit = 1024?#MySQLd能打開文件的最大個數(shù),如果出現(xiàn)too mant open files之類的就需要調整該值了。
back_log = 384?#back_log參數(shù)是值指出在MySQL暫時停止響應新請求之前,短時間內的多少個請求可以被存在堆棧中。如果系統(tǒng)在短時間內有很多連接,則需要增加該參數(shù)的值,該參數(shù)值指定到來的TCP/IP連接的監(jiān)聽隊列的大小。不同的操作系統(tǒng)在這個隊列的大小上有自己的限制。如果試圖將back_log設置得高于操作系統(tǒng)的限制將是無效的,其默認值為50.對于Linux系統(tǒng)而言,推薦設置為小于512的整數(shù)。
max_connections = 800?#指定MySQL允許的最大連接進程數(shù)。如果在訪問博客時經(jīng)常出現(xiàn)
Too Many Connections
的錯誤提示,則需要增大該參數(shù)值。
max_connect_errors = 6000?#設置每個主機的連接請求異常中斷的最大次數(shù),當超過該次數(shù),MySQL服務器將禁止host的連接請求,直到MySQL服務器重啟或通過flush hosts命令清空此host的相關信息。
wait_timeout = 120?#指定一個請求的最大連接時間,對于4GB左右內存的服務器來說,可以將其設置為5~10。
table_cache = 614K?#table_cache指示表高速緩沖區(qū)的大小。當MySQL訪問一個表時,如果在MySQL緩沖區(qū)還有空間,那么這個表就被打開并放入表緩沖區(qū),這樣做的好處是可以更快速地訪問表中的內容。一般來說,可以查看數(shù)據(jù)庫運行峰值時間的狀態(tài)值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?#設置查詢排序時所能使用的緩沖區(qū)大小,系統(tǒng)默認大小為2MB。
注意:該參數(shù)對應的分配內存是每個連接獨占的,如果有100個連接,那么實際分配的總排序緩沖區(qū)大小為100 x6=600MB。所以,對于內存在4GB左右的服務器來說,推薦將其設置為6MB~8MB
join_buffer_size = 8M?#聯(lián)合查詢操作所能使用的緩沖區(qū)大小,和sort_buffer_size一樣,該參數(shù)對應的分配內存也是每個連接獨享。
thread_cache_size = 64?#設置Thread Cache池中可以緩存的連接線程最大數(shù)量,可設置為0~16384,默認為0.這個值表示可以重新利用保存在緩存中線程的數(shù)量,當斷開連接時如果緩存中還有空間,那么客戶端的線程將被放到緩存中;如果線程重新被請求,那么請求將從緩存中讀取,如果緩存中是空的或者是新的請求,那么這個線程將被重新創(chuàng)建,如果有很多線程,增加這個值可以改善系統(tǒng)性能。通過比較Connections和Threads_created狀態(tài)的變量,可以看到這個變量的作用。我們可以根據(jù)物理內存設置規(guī)則如下:1GB內存我們配置為8,2GB內存我們配置為16,3GB我們配置為32,4GB或4GB以上我們給此值為64或更大的值。
thread_concurrency = 8?#該參數(shù)取值為服務器邏輯CPU數(shù)量x 2,在本例中,服務器有兩個物理CPU,而每個物理CPU又支持H.T超線程,所以實際取值為4?x 2 = 8。這也是雙四核主流服務器的配置。
query_cache_size = 64M?#指定MySQL查詢緩沖區(qū)的大小。可以通過在MySQL控制臺觀察,如果Qcache_lowmem_prunes的值非常大,則表明經(jīng)常出現(xiàn)緩沖不夠的情況;如果Qcache_hits的值非常大,則表明查詢緩沖使用得非常頻繁。另外如果改值較小反而會影響效率,那么可以考慮不用查詢緩沖。對于Qcache_free_blocks,如果該值非常大,則表明緩沖區(qū)中碎片很多。
query_cache_limit = 2M?#只有小于此設置值的結果才會被緩存
query_cache_min_res_unit = 2k?#設置查詢緩存分配內存的最小單位,要適當?shù)谠O置此參數(shù),可以做到為減少內存快的申請和分配次數(shù),但是設置過大可能導致內存碎片數(shù)值上升。默認值為4K,建議設置為1K~16K。
default_table_type = InnoDB?#默認表的類型為InnoDB
thread_stack = 256K?#設置MySQL每個線程的堆棧大小,默認值足夠大,可滿足普通操作。可設置范圍為128KB至4GB,默認為192KB
#transaction_isolation = Level?#數(shù)據(jù)庫隔離級別?(READ UNCOMMITTED(讀取未提交內容) READ COMMITTED(讀取提交內容) REPEATABLE READ(可重讀) SERIALIZABLE(可串行化))
tmp_table_size = 64M?#設置內存臨時表最大值。如果超過該值,則會將臨時表寫入磁盤,其范圍1KB到4GB。
max_heap_table_size = 64M?#獨立的內存表所允許的最大容量。
table_cache = 614?#給經(jīng)常訪問的表分配的內存,物理內存越大,設置就越大。調大這個值,一般情況下可以降低磁盤IO,但相應的會占用更多的內存,這里設置為614。
table_open_cache = 512??#設置表高速緩存的數(shù)目。每個連接進來,都會至少打開一個表緩存。因此,?table_cache?的大小應與max_connections?的設置有關。例如,對于?200?個并行運行的連接,應該讓表的緩存至少有?200?×?N?,這里?N?是應用可以執(zhí)行的查詢的一個聯(lián)接中表的最大數(shù)量。此外,還需要為臨時表和文件保留一些額外的文件描述符。
long_query_time = 1?#慢查詢的執(zhí)行用時上限,默認設置是10s,推薦(1s~2s)
log_long_format?#沒有使用索引的查詢也會被記錄。(推薦,根據(jù)業(yè)務來調整)
log-slow-queries = /data/3306/slow.log?#慢查詢日志文件路徑(如果開啟慢查詢,建議打開此日志)
log-bin = /data/3306/mysql-bin?#logbin數(shù)據(jù)庫的操作日志,例如update、delete、create等都會存儲到binlog日志,通過logbin可以實現(xiàn)增量恢復
relay-log = /data/3306/relay-bin?#relay-log日志記錄的是從服務器I/O線程將主服務器的二進制日志讀取過來記錄到從服務器本地文件,然后SQL線程會讀取relay-log日志的內容并應用到從服務器
relay-log-info-file = /data/3306/relay-log.info?#從服務器用于記錄中繼日志相關信息的文件,默認名為數(shù)據(jù)目錄中的relay-log.info。
binlog_cache_size = 4M?#在一個事務中binlog為了記錄sql狀態(tài)所持有的cache大小,如果你經(jīng)常使用大的,多聲明的事務,可以增加此值來獲取更大的性能,所有從事務來的狀態(tài)都被緩沖在binlog緩沖中,然后再提交后一次性寫入到binlog中,如果事務比此值大,會使用磁盤上的臨時文件來替代,此緩沖在每個鏈接的事務第一次更新狀態(tài)時被創(chuàng)建。
max_binlog_cache_size = 8M?#最大的二進制Cache日志緩沖尺寸。
max_binlog_size = 1G?#二進制日志文件的最大長度(默認設置1GB)一個二進制文件信息超過了這個最大長度之前,MySQL服務器會自動提供一個新的二進制日志文件接續(xù)上。
expire_logs_days = 7?#超過7天的binlog,mysql程序自動刪除(如果數(shù)據(jù)重要,建議不要開啟該選項)
key_buffer_size = 256M?#指定用于索引的緩沖區(qū)大小,增加它可得到更好的索引處理性能。對于內存在4GB左右的服務器來說,該參數(shù)可設置為256MB或384MB。
注意:如果該參數(shù)值設置得過大反而會使服務器的整體效率降低!
read_buffer_size = 4M?#讀查詢操作所能使用的緩沖區(qū)大小。和sort_buffer_size一樣,該參數(shù)對應的分配內存也是每個連接獨享。
read_rnd_buffer_size = 16M?#設置進行隨機讀的時候所使用的緩沖區(qū)。此參數(shù)和read_buffer_size所設置的Buffer相反,一個是順序讀的時候使用,一個是隨機讀的時候使用。但是兩者都是針對與線程的設置,每個線程都可以產(chǎn)生兩種Buffer中的任何一個。默認值256KB,最大值4GB。
bulk_insert_buffer_size = 8M?#如果經(jīng)常性的需要使用批量插入的特殊語句來插入數(shù)據(jù),可以適當調整參數(shù)至16MB~32MB,建議8MB。
#myisam_sort_buffer_size = 8M?#設置在REPAIR?Table或用Create index創(chuàng)建索引或?Alter table的過程中排序索引所分配的緩沖區(qū)大小,可設置范圍4Bytes至4GB,默認為8MB
lower_case_table_names = 1?#實現(xiàn)MySQL不區(qū)分大小。(發(fā)開需求–建議開啟)
slave-skip-errors = 1032,1062?#從庫可以跳過的錯誤數(shù)字值(mysql錯誤以數(shù)字代碼反饋,全的mysql錯誤代碼大全,以后會發(fā)布至博客)。
replicate-ignore-db=mysql?#在做主從的情況下,設置不需要同步的庫。
server-id = 1?#表示本機的序列號為1,如果做主從,或者多實例,serverid一定不能相同。
myisam_sort_buffer_size?=?128M?#當需要對于執(zhí)行REPAIR,?OPTIMIZE,?ALTER?語句重建索引時,MySQL會分配這個緩存,以及LOAD?DATA?INFILE會加載到一個新表,它會根據(jù)最大的配置認真的分配的每個線程。
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存儲的數(shù)據(jù)目錄信息和其他內部數(shù)據(jù)結構的內存池大小。應用程序里的表越多,你需要在這里面分配越多的內存。對于一個相對穩(wěn)定的應用,這個參數(shù)的大小也是相對穩(wěn)定的,也沒有必要預留非常大的值。如果InnoDB用廣了這個池內的內存,InnoDB開始從操作系統(tǒng)分配內存,并且往MySQL錯誤日志寫警告信息。默認為1MB,當發(fā)現(xiàn)錯誤日志中已經(jīng)有相關的警告信息時,就應該適當?shù)脑黾釉搮?shù)的大小。
innodb_buffer_pool_size = 64M?#InnoDB使用一個緩沖池來保存索引和原始數(shù)據(jù),設置越大,在存取表里面數(shù)據(jù)時所需要的磁盤I/O越少。強烈建議不要武斷地將InnoDB的Buffer Pool值配置為物理內存的50%~80%,應根據(jù)具體環(huán)境而定。
innodb_data_file_path = ibdata1:128M:autoextend?#設置配置一個可擴展大小的尺寸為128MB的單獨文件,名為ibdata1.沒有給出文件的位置,所以默認的是在MySQL的數(shù)據(jù)目錄內。
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隊列滿后在統(tǒng)一存儲,默認為1,也是最安全的設置。
innodb_log_buffer_size = 2M?#默認為1MB,通常設置為8~16MB就足夠了。
innodb_log_file_size = 32M?#確定日志文件的大小,更大的設置可以提高性能,但也會增加恢復數(shù)據(jù)庫的時間。
innodb_log_files_in_group = 3?#為提高性能,MySQL可以以循環(huán)方式將日志文件寫到多個文件。推薦設置為3。
innodb_max_dirty_pages_pct = 90?#InnoDB主線程刷新緩存池中的數(shù)據(jù)。
innodb_lock_wait_timeout = 120?#InnoDB事務被回滾之前可以等待一個鎖定的超時秒數(shù)。InnoDB在它自己的鎖定表中自動檢測事務死鎖并且回滾事務。InnoDB用locak tables?語句注意到鎖定設置。默認值是50秒。
innodb_file_per_table = 0?#InnoDB為獨立表空間模式,每個數(shù)據(jù)庫的每個表都會生成一個數(shù)據(jù)空間。0關閉,1開啟。
獨立表空間優(yōu)點:
1、每個表都有自己獨立的表空間。
2、每個表的數(shù)據(jù)和索引都會存在自己的表空間中。
3、可以實現(xiàn)單表在不同的數(shù)據(jù)庫中移動。
4、空間可以回收(除drop table操作處,表空不能自己回收。)
[mysqldump]
quick
max_allowed_packet = 2M?#設定在網(wǎng)絡傳輸中一次消息傳輸量的最大值。系統(tǒng)默認值為1MB,最大值是1GB,必須設置為1024的倍數(shù)。單位為字節(jié)。
[mysqld_safe]
值得注意:
強烈建議不要武斷地將InnoDB的Buffer Pool值配置為物理內存的50%~80%,應根據(jù)具體環(huán)境而定。
如果key_reads太大,則應該把my.cnf中的key_buffer_size變大,保持key_reads/key_read_re-quests至少在1/100以上,越小越好。
如果qcache_lowmem_prunes很大,就要增加query_cache_size的值。
電商MySQL數(shù)據(jù)庫配置文件
這是一份電子商務網(wǎng)站MySQL數(shù)據(jù)庫調整后所運行的配置文件/etc/my.cnf(服務器為DELL R710、16GB內存、RAID10),大家可以根據(jù)實際的MySQL數(shù)據(jù)庫硬件情況進行調整配置文件如下:
[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