MySQL性能優(yōu)化配置參數(shù)之thread_cache和table_cache詳解

更新時間：2014年07月04日 09:45:23 投稿：junjie

這篇文章主要介紹了MySQL性能優(yōu)化配置參數(shù)之thread_cache和table_cache詳解,THREAD_CACHE是Mysql的連接池,table_cache指定表高速緩存的大小,需要的朋友可以參考下

一、THREAD_CACHE

MySQL里面為了提高客戶端請求創(chuàng)建連接過程的性能,提供了一個連接池也就是 Thread_Cache池,將空閑的連接線程放在連接池中,而不是立即銷毀.這樣的好處就是,當(dāng)又有一個新的請求的時候,mysql不會立即去創(chuàng)建連接線程,而是先去Thread_Cache中去查找空閑的連接線程,如果存在則直接使用,不存在才創(chuàng)建新的連接線程.

有關(guān)Thread_Cache在MySQL有幾個重要的參數(shù),簡單介紹如下:

thread_cache_size

Thread_Cache 中存放的最大連接線程數(shù).在短連接的應(yīng)用中Thread_Cache的功效非常明顯,因?yàn)樵趹?yīng)用中數(shù)據(jù)庫的連接和創(chuàng)建是非常頻繁的,如果不使用 Thread_Cache那么消耗的資源是非常可觀的!在長連接中雖然帶來的改善沒有短連接的那么明顯,但是好處是顯而易見的.但并不是越大越好大了反而浪費(fèi)資源這個的確定一般認(rèn)為和物理內(nèi)存有一定關(guān)系,如下:

復(fù)制代碼代碼如下:

1G —> 8

2G —> 16

3G —> 32

>3G —> 64

如果短連接多的話可以適當(dāng)加大.

thread_stack

每個連接被創(chuàng)建的時候,mysql分配給它的內(nèi)存.這個值一般認(rèn)為默認(rèn)就可以應(yīng)用于大部分場景了,除非必要非則不要動它.

thread_handing

運(yùn)用Thread_Cache處理連接的方式,5.1.19添加的新特性.有兩個值可選[no-threads|one-thread-per-connection] 看字面意思大家也該猜出八九分了,呵呵,no-threads 服務(wù)器使用一個線程,one-thread-per-connection 服務(wù)器為每個客戶端請求使用一個線程.原手冊中提到,no-threads是在Linux下調(diào)試用的.

復(fù)制代碼代碼如下:

mysql> show status like '%thread%';
+————————+——–+
| Variable_name          | Value |
+————————+——–+
| Delayed_insert_threads | 0      |
| Slow_launch_threads    | 0      |
| Threads_cached         | 3      |
| Threads_connected      | 6      |
| Threads_created        | 8689   |
| Threads_running        | 5      |
+————————+——–+
6 rows in set (0.00 sec)

通過以上3個命令,可以看到服務(wù)器的 thread_cache池中最多可以存放32個連接線程,為每個客戶端球使用一個線程.為每個連接的線程分配192k的內(nèi)存空間.

服務(wù)器總共有199156次連接,最大并發(fā)連接數(shù)為31,當(dāng)前在thread_cashe池中的連接數(shù)為3個,連接數(shù)為6個,處于活躍狀態(tài)的有5個,共創(chuàng)建了8689次連接.顯然這里以短連接為主.可以算出thread_cache命中率,公式為:

復(fù)制代碼代碼如下:

Thread_Cache_Hit=(Connections-Thread_created)/Connections*100%

當(dāng)前服務(wù)器的Thread_cache命中率約為95.6%這個結(jié)果我還是比較滿意的.但是可以看出 thread_cache_size有點(diǎn)多余改成16或8更合理一些.

二、TABLE_CACHE(5.1.3及以后版本又名TABLE_OPEN_CACHE)

由于MySQL是多線程的機(jī)制,為了提高性能,每個線程都是獨(dú)自打開自己需要的表的文件描述符,而不是通過共享已經(jīng)打開的.針對不同存儲引擎處理的方法當(dāng)然也不一樣.

在myisam表引擎中,數(shù)據(jù)文件的描述符 (descriptor)是不共享的,但是索引文件的描述符卻是所有線程共享的.Innodb中和使用表空間類型有關(guān),假如是共享表空間那么實(shí)際就一個數(shù) 據(jù)文件,當(dāng)然占用的數(shù)據(jù)文件描述符就會比獨(dú)立表空間少.

個人感覺有點(diǎn)像php里面的fopen打開一個連接,操作完數(shù)據(jù)之后,并不立即關(guān)閉,而是緩存起來,等待下一個連接這個文件的請求就不必去重新打開文件了,不知樣理解對不對,哈.

手冊上有段關(guān)于打開表時的描述:

復(fù)制代碼代碼如下:

A MyISAM table is opened for each concurrent access. This means the table needs to be opened twice if two threads access the same table or if a thread accesses the table twice in the same query (for example, by joining the table to itself). Each concurrent open requires an entry in the table cache. The first open of any MyISAM table takes two file descriptors: one for the data file and one for the index file. Each additional use of the table takes only one file descriptor for the data file. The index file descriptor is shared among all threads.

如果你正用 HANDLER tbl_name OPEN語句打開一個表，將為該線程專門分配一個表。該表不被其它線程共享，只有線程調(diào)用HANDLER tbl_name CLOSE或線程終止后才被關(guān)閉。表關(guān)閉后，被拉回表緩存中(如果緩存不滿)。

mysql手冊上給的建議大小是:table_cache=max_connections*n

n表示查詢語句中最大表數(shù), 還需要為臨時表和文件保留一些額外的文件描述符。

這個數(shù)據(jù)遭到很多質(zhì)疑,table_cache夠用就好,檢查 Opened_tables值,如果這個值很大,或增長很快那么你就得考慮加大table_cache了.

在下面的條件下，未使用的表將被關(guān)閉并從表緩存中移出：

當(dāng)緩存滿了并且一個線程試圖打開一個不在緩存中的表時。

當(dāng)緩存包含超過table_cache個條目，并且緩存中的表不再被任何線程使用。

當(dāng)表刷新操作發(fā)生。當(dāng)執(zhí)行FLUSH TABLES語句或執(zhí)行mysqladmin flush-tables或mysqladmin refresh命令時會發(fā)生。

當(dāng)表緩存滿時，服務(wù)器使用下列過程找到一個緩存入口來使用：

當(dāng)前未使用的表被釋放，以最近最少使用順序。

如果緩存滿了并且沒有表可以釋放，但是一個新表需要打開，緩存必須臨時被擴(kuò)大。

如果緩存處于一個臨時擴(kuò)大狀態(tài)并且一個表從在用變?yōu)椴辉谟脿顟B(tài)，它被關(guān)閉并從緩存中釋放。