1、目的：
通過(guò)根據服務(wù)器目前狀況，修改Mysql的系統參數，達到合理利用服務(wù)器現有資源，最大合理的提高M(jìn)ySQL性能。
2、服務(wù)器參數：
32G內存、4個(gè)CPU,每個(gè)CPU 8核。
3、MySQL目前安裝狀況。
MySQL目前安裝，用的是MySQL默認的最大支持配置?？截惖氖莔y-huge.cnf.編碼已修改為UTF-8.具體修改及安裝MySQL,可以參考<<Linux系統上安裝MySQL 5.5>>幫助文檔。
4、修改MySQL配置
打開(kāi)MySQL配置文件my.cnf
vi /etc/my.cnf
4.1 MySQL非緩存參數變量介紹及修改
4.1.1修改back_log參數值:由默認的50修改為500.（每個(gè)連接256kb,占用：125M）
back_log=500
back_log值指出在MySQL暫時(shí)停止回答新請求之前的短時(shí)間內多少個(gè)請求可以被存在堆棧中。也就是說(shuō)，如果MySql的連接數據達到max_connections時(shí)，新來(lái)的請求將會(huì )被存在堆棧中，以等待某一連接釋放資源，該堆棧的數量即back_log，如果等待連接的數量超過(guò)back_log，將不被授予連接資源。將會(huì )報：unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待連接進(jìn)程時(shí).
back_log值不能超過(guò)TCP/IP連接的偵聽(tīng)隊列的大小。若超過(guò)則無(wú)效，查看當前系統的TCP/IP連接的偵聽(tīng)隊列的大小命令：cat /proc/sys/net/ipv4/tcp_max_syn_backlog目前系統為1024。對于Linux系統推薦設置為小于512的整數。
修改系統內核參數，）http://www.51testing.com/html/64/n-810764.html
查看mysql 當前系統默認back_log值，命令：
show variables like 'back_log'; 查看當前數量
4.1.2修改wait_timeout參數值，由默認的8小時(shí)，修改為30分鐘。(本次不用)
wait_timeout=1800（單位為妙）
我對wait-timeout這個(gè)參數的理解：MySQL客戶(hù)端的數據庫連接閑置最大時(shí)間值。
說(shuō)得比較通俗一點(diǎn)，就是當你的MySQL連接閑置超過(guò)一定時(shí)間后將會(huì )被強行關(guān)閉。MySQL默認的wait-timeout 值為8個(gè)小時(shí)，可以通過(guò)命令show variables like 'wait_timeout'查看結果值;。
設置這個(gè)值是非常有意義的，比如你的網(wǎng)站有大量的MySQL鏈接請求（每個(gè)MySQL連接都是要內存資源開(kāi)銷(xiāo)的 ），由于你的程序的原因有大量的連接請求空閑啥事也不干，白白占用內存資源，或者導致MySQL超過(guò)最大連接數從來(lái)無(wú)法新建連接導致“Too many connections”的錯誤。在設置之前你可以查看一下你的MYSQL的狀態(tài)（可用show processlist)，如果經(jīng)常發(fā)現MYSQL中有大量的Sleep進(jìn)程，則需要 修改wait-timeout值了。
interactive_timeout：服務(wù)器關(guān)閉交互式連接前等待活動(dòng)的秒數。交互式客戶(hù)端定義為在mysql_real_connect()中使用CLIENT_INTERACTIVE選項的客戶(hù)端。
wait_timeout:服務(wù)器關(guān)閉非交互連接之前等待活動(dòng)的秒數。在線(xiàn)程啟動(dòng)時(shí)，根據全局wait_timeout值或全局 interactive_timeout值初始化會(huì )話(huà)wait_timeout值，取決于客戶(hù)端類(lèi)型(由mysql_real_connect()的連接選項CLIENT_INTERACTIVE定義).
這兩個(gè)參數必須配合使用。否則單獨設置wait_timeout無(wú)效
4.1.3修改max_connections參數值，由默認的151，修改為3000（750M）。
max_connections=3000
max_connections是指MySql的最大連接數，如果服務(wù)器的并發(fā)連接請求量比較大，建議調高此值，以增加并行連接數量，當然這建立在機器能支撐的情況下，因為如果連接數越多，介于MySql會(huì )為每個(gè)連接提供連接緩沖區，就會(huì )開(kāi)銷(xiāo)越多的內存，所以要適當調整該值，不能盲目提高設值?？梢赃^(guò)'conn%'通配符查看當前狀態(tài)的連接數量，以定奪該值的大小。
MySQL服務(wù)器允許的最大連接數16384；
查看系統當前最大連接數：
show variables like 'max_connections';
4.1..4修改max_user_connections值，由默認的0，修改為800
max_user_connections=800
max_user_connections是指每個(gè)數據庫用戶(hù)的最大連接
針對某一個(gè)賬號的所有客戶(hù)端并行連接到MYSQL服務(wù)的最大并行連接數。簡(jiǎn)單說(shuō)是指同一個(gè)賬號能夠同時(shí)連接到mysql服務(wù)的最大連接數。設置為0表示不限制。
目前默認值為：0不受限制。
這兒順便介紹下Max_used_connections:它是指從這次mysql服務(wù)啟動(dòng)到現在，同一時(shí)刻并行連接數的最大值。它不是指當前的連接情況，而是一個(gè)比較值。如果在過(guò)去某一個(gè)時(shí)刻，MYSQL服務(wù)同時(shí)有1000個(gè)請求連接過(guò)來(lái)，而之后再也沒(méi)有出現這么大的并發(fā)請求時(shí)，則Max_used_connections=1000.請注意與show variables 里的max_user_connections的區別。默認為0表示無(wú)限大。
查看max_user_connections值
show variables like 'max_user_connections';
4.1.5修改thread_concurrency值，由目前默認的8，修改為64
thread_concurrency=64
thread_concurrency的值的正確與否, 對mysql的性能影響很大, 在多個(gè)cpu(或多核)的情況下，錯誤設置了thread_concurrency的值, 會(huì )導致mysql不能充分利用多cpu(或多核), 出現同一時(shí)刻只能一個(gè)cpu(或核)在工作的情況。
thread_concurrency應設為CPU核數的2倍. 比如有一個(gè)雙核的CPU, 那thread_concurrency 的應該為4; 2個(gè)雙核的cpu, thread_concurrency的值應為8.
比如：根據上面介紹我們目前系統的配置，可知道為4個(gè)CPU,每個(gè)CPU為8核，按照上面的計算規則，這兒應為:4*8*2=64
查看系統當前thread_concurrency默認配置命令：
show variables like 'thread_concurrency';
4.1.6添加skip-name-resolve，默認被注釋掉，沒(méi)有該參數。
skip-name-resolve
skip-name-resolve：禁止MySQL對外部連接進(jìn)行DNS解析，使用這一選項可以消除MySQL進(jìn)行DNS解析的時(shí)間。但需要注意，如果開(kāi)啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無(wú)法正常處理連接請求！
4.1.7 skip-networking，默認被注釋掉。沒(méi)有該參數。（本次無(wú)用）
skip-networking建議被注釋掉，不要開(kāi)啟
開(kāi)啟該選項可以徹底關(guān)閉MySQL的TCP/IP連接方式，如果WEB服務(wù)器是以遠程連接的方式訪(fǎng)問(wèn)MySQL數據庫服務(wù)器則不要開(kāi)啟該選項！否則將無(wú)法正常連接！
4.1.8 default-storage-engine(設置MySQL的默認存儲引擎)
default-storage-engine= InnoDB(設置InnoDB類(lèi)型，另外還可以設置MyISAM類(lèi)型)
設置創(chuàng )建數據庫及表默認存儲類(lèi)型
show table status like ‘tablename’顯示表的當前存儲狀態(tài)值
查看MySQL有哪些存儲狀態(tài)及默認存儲狀態(tài)
show engines;
創(chuàng )建表并指定存儲類(lèi)型
CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB;
修改表存儲類(lèi)型：
Alter table tableName engine =engineName
備注：設置完后把以下幾個(gè)開(kāi)啟：
# 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（要注釋掉，否則會(huì )創(chuàng )建一個(gè)新的把原來(lái)的替換的。）
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起動(dòng)失敗。
4.2 MySQL緩存變量介紹及修改
數據庫屬于IO密集型的應用程序，其主職責就是數據的管理及存儲工作。而我們知道，從內存中讀取一個(gè)數據庫的時(shí)間是微秒級別，而從一塊普通硬盤(pán)上讀取一個(gè) IO是在毫秒級別，二者相差3個(gè)數量級。所以，要優(yōu)化數據庫，首先第一步需要優(yōu)化的就是IO，盡可能將磁盤(pán)IO轉化為內存IO。本文先從MySQL數據庫 IO相關(guān)參數(緩存參數)的角度來(lái)看看可以通過(guò)哪些參數進(jìn)行IO優(yōu)化
4.2.1全局緩存
啟動(dòng)MySQL時(shí)就要分配并且總是存在的全局緩存。目前有：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)等五個(gè)?？偣玻?60M.
這些變量值都可以通過(guò)命令如：show variables like '變量名';查看到。
4.2.1.1：key_buffer_size,本系統目前為384M,可修改為400M
key_buffer_size=400M
key_buffer_size是用于索引塊的緩沖區大小，增加它可得到更好處理的索引(對所有讀和多重寫(xiě))，對MyISAM(MySQL表存儲的一種類(lèi)型，可以百度等查看詳情)表性能影響最大的一個(gè)參數。如果你使它太大，系統將開(kāi)始換頁(yè)并且真的變慢了。嚴格說(shuō)是它決定了數據庫索引處理的速度，尤其是索引讀的速度。對于內存在4GB左右的服務(wù)器該參數可設置為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%';
比如查看系統當前key_read和key_read_request值為：
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Key_read_requests | 28535 |
| Key_reads | 269 |
+-------------------+-------+
可知道有28535個(gè)請求，有269個(gè)請求在內存中沒(méi)有找到直接從硬盤(pán)讀取索引.
未命中緩存的概率為：0.94%=269/28535*100%. 一般未命中概率在0.1之下比較好。目前已遠遠大于0.1，證明效果不好。若命中率在0.01以下，則建議適當的修改key_buffer_size值。
http://dbahacker.com/mysql/innodb-myisam-compare(
InnoDB與MyISAM的六大區別)
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表性能影響最大的一個(gè)參數。功能與Key_buffer_size一樣。InnoDB占用的內存，除innodb_buffer_pool_size用于存儲頁(yè)面緩存數據外，另外正常情況下還有大約8%的開(kāi)銷(xiāo)，主要用在每個(gè)緩存頁(yè)幀的描述、adaptive hash等數據結構，如果不是安全關(guān)閉，啟動(dòng)時(shí)還要恢復的話(huà)，還要另開(kāi)大約12%的內存用于恢復，兩者相加就有差不多21%的開(kāi)銷(xiāo)。假設：12G的innodb_buffer_pool_size，最多的時(shí)候InnoDB就可能占用到14.5G的內存。若系統只有16G，而且只運行MySQL，且MySQL只用InnoDB，
那么為MySQL開(kāi)12G，是最大限度地利用內存了。
另外InnoDB和 MyISAM 存儲引擎不同， MyISAM 的 key_buffer_size 只能緩存索引鍵，而 innodb_buffer_pool_size 卻可以緩存數據塊和索引鍵。適當的增加這個(gè)參數的大小，可以有效的減少 InnoDB 類(lèi)型的表的磁盤(pán) I/O 。
當我們操作一個(gè) InnoDB 表的時(shí)候，返回的所有數據或者去數據過(guò)程中用到的任何一個(gè)索引塊，都會(huì )在這個(gè)內存區域中走一遭。
可以通過(guò) (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 計算緩存命中率，并根據命中率來(lái)調整 innodb_buffer_pool_size 參數大小進(jìn)行優(yōu)化。值可以用以下命令查得：show status like 'Innodb_buffer_pool_read%';
比如查看當前系統中系統中
| 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存儲引擎用來(lái)存放數據字典信息以及一些內部數據結構的內存空間大小，所以當我們一個(gè)MySQL Instance中的數據庫對象非常多的時(shí)候，是需要適當調整該參數的大小以確保所有數據都能存放在內存中提高訪(fǎng)問(wèn)效率的。
這個(gè)參數大小是否足夠還是比較容易知道的，因為當過(guò)小的時(shí)候，MySQL會(huì )記錄Warning信息到數據庫的error log中，這時(shí)候你就知道該調整這個(gè)參數大小了。
查看當前系統mysql的error日志 cat /var/lib/mysql/機器名.error 發(fā)現有很多waring警告。所以要調大為20M.
根據MySQL手冊，對于2G內存的機器，推薦值是20M。
32G內存的 100M
4.2.1.4：innodb_log_buffer_size(默認8M)
innodb_log_buffer_size=20M
innodb_log_buffer_size 這是InnoDB存儲引擎的事務(wù)日志所使用的緩沖區。類(lèi)似于Binlog Buffer，InnoDB在寫(xiě)事務(wù)日志的時(shí)候，為了提高性能，也是先將信息寫(xiě)入Innofb Log Buffer中，當滿(mǎn)足innodb_flush_log_trx_commit參數所設置的相應條件(或者日志緩沖區寫(xiě)滿(mǎn))之后，才會(huì )將日志寫(xiě)到文件 (或者同步到磁盤(pán))中?？梢酝ㄟ^(guò)innodb_log_buffer_size 參數設置其可以使用的最大內存空間。
InnoDB 將日志寫(xiě)入日志磁盤(pán)文件前的緩沖大小。理想值為 1M 至 8M。大的日志緩沖允許事務(wù)運行時(shí)不需要將日志保存入磁盤(pán)而只到事務(wù)被提交(commit)。 因此，如果有大的事務(wù)處理，設置大的日志緩沖可以減少磁盤(pán)I/O。 在 my.cnf中以數字格式設置。
默認是8MB，系的如頻繁的系統可適當增大至4MB～8MB。當然如上面介紹所說(shuō)，這個(gè)參數實(shí)際上還和另外的flush參數相關(guān)。一般來(lái)說(shuō)不建議超過(guò)32MB
注：innodb_flush_log_trx_commit參數對InnoDB Log的寫(xiě)入性能有非常關(guān)鍵的影響,默認值為1。該參數可以設置為0，1，2，解釋如下：
0：log buffer中的數據將以每秒一次的頻率寫(xiě)入到log file中，且同時(shí)會(huì )進(jìn)行文件系統到磁盤(pán)的同步操作，但是每個(gè)事務(wù)的commit并不會(huì )觸發(fā)任何log buffer 到log file的刷新或者文件系統到磁盤(pán)的刷新操作;
1：在每次事務(wù)提交的時(shí)候將log buffer 中的數據都會(huì )寫(xiě)入到log file，同時(shí)也會(huì )觸發(fā)文件系統到磁盤(pán)的同步;
2：事務(wù)提交會(huì )觸發(fā)log buffer到log file的刷新，但并不會(huì )觸發(fā)磁盤(pán)文件系統到磁盤(pán)的同步。此外，每秒會(huì )有一次文件系統到磁盤(pán)同步操作。
實(shí)際測試發(fā)現，該值對插入數據的速度影響非常大，設置為2時(shí)插入10000條記錄只需要2秒，設置為0時(shí)只需要1秒，而設置為1時(shí)則需要229秒。因此，MySQL手冊也建議盡量將插入操作合并成一個(gè)事務(wù)，這樣可以大幅提高速度。根據MySQL手冊，在存在丟失最近部分事務(wù)的危險的前提下，可以把該值設為0。
4.5.1.5：query_cache_size(默認32M)
query_cache_size=40M
query_cache_size: 主要用來(lái)緩存MySQL中的ResultSet，也就是一條SQL語(yǔ)句執行的結果集，所以?xún)H僅只能針對select語(yǔ)句。當我們打開(kāi)了 Query Cache功能，MySQL在接受到一條select語(yǔ)句的請求后，如果該語(yǔ)句滿(mǎn)足Query Cache的要求(未顯式說(shuō)明不允許使用Query Cache，或者已經(jīng)顯式申明需要使用Query Cache)，MySQL會(huì )直接根據預先設定好的HASH算法將接受到的select語(yǔ)句以字符串方式進(jìn)行hash，然后到Query Cache中直接查找是否已經(jīng)緩存。也就是說(shuō)，如果已經(jīng)在緩存中，該select請求就會(huì )直接將數據返回，從而省略了后面所有的步驟(如SQL語(yǔ)句的解析，優(yōu)化器優(yōu)化以及向存儲引擎請求數據等)，極大的提高性能。根據MySQL用戶(hù)手冊，使用查詢(xún)緩沖最多可以達到238%的效率。
當然，Query Cache也有一個(gè)致命的缺陷，那就是當某個(gè)表的數據有任何任何變化，都會(huì )導致所有引用了該表的select語(yǔ)句在Query Cache中的緩存數據失效。所以，當我們的數據變化非常頻繁的情況下，使用Query Cache可能會(huì )得不償失
Query Cache的使用需要多個(gè)參數配合，其中最為關(guān)鍵的是query_cache_size和query_cache_type，前者設置用于緩存 ResultSet的內存大小，后者設置在何場(chǎng)景下使用Query Cache。在以往的經(jīng)驗來(lái)看，如果不是用來(lái)緩存基本不變的數據的MySQL數據庫，query_cache_size一般256MB是一個(gè)比較合適的大小。當然，這可以通過(guò)計算Query Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))來(lái)進(jìn)行調整。 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)常出現緩沖. 如果Qcache_hits的值也非常大，則表明查詢(xún)緩沖使用非常頻繁，此時(shí)需要增加緩沖大??；
根據命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))進(jìn)行調整，一般不建議太大，256MB可能已經(jīng)差不多了，大型的配置型靜態(tài)數據可適當調大.
可以通過(guò)命令：show status like 'Qcache_%';查看目前系統Query catch使用大小
| Qcache_hits | 1892463 |
| Qcache_inserts | 35627
命中率98.17%=1892463/(1892463 +35627 )*100
4.2.2局部緩存
除了全局緩沖，MySql還會(huì )為每個(gè)連接發(fā)放連接緩沖。個(gè)連接到MySQL服務(wù)器的線(xiàn)程都需要有自己的緩沖。大概需要立刻分配256K，甚至在線(xiàn)程空閑時(shí)，它們使用默認的線(xiàn)程堆棧，網(wǎng)絡(luò )緩存等。事務(wù)開(kāi)始之后，則需要增加更多的空間。運行較小的查詢(xún)可能僅給指定的線(xiàn)程增加少量的內存消耗，然而如果對數據表做復雜的操作例如掃描、排序或者需要臨時(shí)表，則需分配大約read_buffer_size，
sort_buffer_size，read_rnd_buffer_size，tmp_table_size 大小的內存空間. 不過(guò)它們只是在需要的時(shí)候才分配，并且在那些操作做完之后就釋放了。有的是立刻分配成單獨的組塊。tmp_table_size 可能高達MySQL所能分配給這個(gè)操作的最大內存空間了
。注意，這里需要考慮的不只有一點(diǎn)——可能會(huì )分配多個(gè)同一種類(lèi)型的緩存，例如用來(lái)處理子查詢(xún)。一些特殊的查詢(xún)的內存使用量可能更大——如果在MyISAM表上做成批的插入
時(shí)需要分配 bulk_insert_buffer_size 大小的內存；執行 ALTER TABLE， OPTIMIZE TABLE， REPAIR TABLE 命令時(shí)需要分配 myisam_sort_buffer_size 大小的內存。
4.2.2.1：read_buffer_size（默認值：2097144即2M）
read_buffer_size=4M
read_buffer_size 是MySql讀入緩沖區大小。對表進(jìn)行順序掃描的請求將分配一個(gè)讀入緩沖區，MySql會(huì )為它分配一段內存緩沖區。read_buffer_size變量控制這一
緩沖區的大小。如果對表的順序掃描請求非常頻繁，并且你認為頻繁掃描進(jìn)行得太慢，可以通過(guò)增加該變量值以及內存緩沖區大小提高其性能.
4.2.2.2：sort_buffer_size（默認值：2097144即2M）
sort_buffer_size=4M
sort_buffer_size是MySql執行排序使用的緩沖大小。如果想要增加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的隨機讀緩沖區大小。當按任意順序讀取行時(shí)(例如，按照排序順序)，將分配一個(gè)隨機讀緩存區。進(jìn)行排序查詢(xún)時(shí)，MySql會(huì )首先掃描一遍該緩沖，以避免磁盤(pán)搜索，提高查詢(xún)速度，如果需要排序大量數據，可適當調高該值。但MySql會(huì )為每個(gè)客戶(hù)連接發(fā)放該緩沖空間，所以應盡量適當設置該值，以避免內存開(kāi)
銷(xiāo)過(guò)大。
4.2.2.4: tmp_table_size(默認值：8388608 即：16M)
tmp_table_size=16M
tmp_table_size是MySql的heap （堆積）表緩沖大小。所有聯(lián)合在一個(gè)DML指令內完成，并且大多數聯(lián)合甚至可以不用臨時(shí)表即可以完成。大多數臨時(shí)表是基于內
存的(HEAP)表。具有大的記錄長(cháng)度的臨時(shí)表 (所有列的長(cháng)度的和)或包含BLOB列的表存儲在硬盤(pán)上。如果某個(gè)內部heap（堆積）表大小超過(guò)tmp_table_size，MySQL可以根據需要自
動(dòng)將內存中的heap表改為基于硬盤(pán)的MyISAM表。還可以通過(guò)設置tmp_table_size選項來(lái)增加臨時(shí)表的大小。也就是說(shuō)，如果調高該值，MySql同時(shí)將增加heap表的大小，可達到提高
聯(lián)接查詢(xún)速度的效果。
4.2.2.5：record_buffer:（默認值：）
record_buffer每個(gè)進(jìn)行一個(gè)順序掃描的線(xiàn)程為其掃描的每張表分配這個(gè)大小的一個(gè)緩沖區。如果你做很多順序掃描，你可能想要增加該值。默認數值是131072
(128K)
4.2.3其它緩存：
4.2.3.1：table_cache(默認值：512)
TABLE_CACHE(5.1.3及以后版本又名TABLE_OPEN_CACHE)
table_cache指定表高速緩存的大小。每當MySQL訪(fǎng)問(wèn)一個(gè)表時(shí)，如果在表緩沖區中還有空間，該表就被打開(kāi)并放入其中，這樣可以更快地訪(fǎng)問(wèn)表內容。通過(guò)檢查峰值時(shí)間的狀態(tài)值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發(fā)現open_tables等于table_cache，并且opened_tables在不斷增長(cháng)，那么你就需要增加table_cache的值了（上述狀態(tài)值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會(huì )造成文件描述符不足，從而造成性能不穩定或者連接失敗。
SHOW STATUS LIKE 'Open%tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 356 |
| Opened_tables | 0 |
+---------------+-------+
2 rows in set (0.00 sec)
open_tables表示當前打開(kāi)的表緩存數，如果執行flush tables操作，則此系統會(huì )關(guān)閉一些當前沒(méi)有使用的表緩存而使得此狀態(tài)值減??；
opend_tables表示曾經(jīng)打開(kāi)的表緩存數，會(huì )一直進(jìn)行累加，如果執行flush tables操作，值不會(huì )減小。
在mysql默認安裝情況下，table_cache的值在2G內存以下的機器中的值默認時(shí)256到512，如果機器有4G內存,則默認這個(gè)值 是2048，但這決意味著(zhù)機器內存越大，這個(gè)值應該越大，因為table_cache加大后，使得mysql對SQL響應的速度更快了，不可避免的會(huì )產(chǎn)生 更多的死鎖（dead lock），這樣反而使得數據庫整個(gè)一套操作慢了下來(lái)，嚴重影響性能。所以平時(shí)維護中還是要根據庫的實(shí)際情況去作出判斷，找到最適合你維護的庫的 table_cache值。
由于MySQL是多線(xiàn)程的機制,為了提高性能,每個(gè)線(xiàn)程都是獨自打開(kāi)自己需要的表的文件描 述符,而不是通過(guò)共享已經(jīng)打開(kāi)的.針對不同存儲引擎處理的方法當然也不一樣
在myisam表引擎中,數據文件的描述符 (descriptor)是不共享的,但是索引文件的描述符卻是所有線(xiàn)程共享的.Innodb中和使用表空間類(lèi)型有關(guān),假如是共享表空間那么實(shí)際就一個(gè)數 據文件,當然占用的數據文件描述符就會(huì )比獨立表空間少.
mysql手冊上給的建議大小 是:table_cache=max_connections*n
n表示查詢(xún)語(yǔ)句中最大表數, 還需要為臨時(shí)表和文件保留一些額外的文件描述符。
這個(gè)數據遭到很多質(zhì)疑,table_cache夠用就好,檢查 Opened_tables值,如果這個(gè)值很大,或增長(cháng)很快那么你就得考慮加大table_cache了.
table_cache：所有線(xiàn)程打開(kāi)的表的數目。增大該值可以增加mysqld需要的文件描述符的數量。默認值是64.
4.2.3.2 thread_cache_size (服務(wù)器線(xiàn)程緩存)
thread_cache_size=64
默認的thread_cache_size=8，但是看到好多配置的樣例里的值一般是32，64，甚至是128，感覺(jué)這個(gè)參數對優(yōu)化應該有幫助，于是查了下：
根據調查發(fā)現以上服務(wù)器線(xiàn)程緩存thread_cache_size沒(méi)有進(jìn)行設置，或者設置過(guò)小,這個(gè)值表示可以重新利用保存在緩存中線(xiàn)程的數量,當斷開(kāi)連接時(shí)如果緩存中還有空間,那么客戶(hù)端的線(xiàn)程將被放到緩存中,如果線(xiàn)程重新被請求，那么請求將從緩存中讀取,如果緩存中是空的或者是新的請求，那么這個(gè)線(xiàn)程將被重新創(chuàng )建,如果有很多新的線(xiàn)程，增加這個(gè)值可以改善系統性能.通過(guò)比較 Connections 和 Threads_created 狀態(tài)的變量，可以看到這個(gè)變量的作用。(–>表示要調整的值) 根據物理內存設置規則如下：
1G —> 8
2G —> 16
3G —> 32 >3G —> 64
mysql> show status like 'thread%';
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| Threads_cached | 0 | <—當前被緩存的空閑線(xiàn)程的數量
| Threads_connected | 1 | <—正在使用（處于連接狀態(tài)）的線(xiàn)程
| Threads_created | 1498 | <—服務(wù)啟動(dòng)以來(lái)，創(chuàng )建了多少個(gè)線(xiàn)程
| Threads_running | 1 | <—正在忙的線(xiàn)程（正在查詢(xún)數據，傳輸數據等等操作）
+——————-+——-+
查看開(kāi)機起來(lái)數據庫被連接了多少次？
mysql> show status like '%connection%';
+———————-+——-+
| Variable_name | Value |
+———————-+——-+
| Connections | 1504 | –>服務(wù)啟動(dòng)以來(lái)，歷史連接數
| Max_used_connections | 2 |
+———————-+——-+
通過(guò)連接線(xiàn)程池的命中率來(lái)判斷設置值是否合適？命中率超過(guò)90%以上,設定合理。
(Connections - Threads_created) / Connections * 100 %
