MySQL機能優化設置裝備擺設參數之thread_cache和table_cache詳解。本站提示廣大學習愛好者：（MySQL機能優化設置裝備擺設參數之thread_cache和table_cache詳解）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL機能優化設置裝備擺設參數之thread_cache和table_cache詳解正文
1、THREAD_CACHE
MySQL外面為了進步客戶端要求創立銜接進程的機能,供給了一個銜接池也就是 Thread_Cache池,將余暇的銜接線程放在銜接池中,而不是立刻燒毀.如許的利益就是,當又有一個新的要求的時刻,mysql不會立刻去創立銜接 線程,而是先去Thread_Cache中去查找余暇的銜接線程,假如存在則直接應用,不存在才創立新的銜接線程.
有關Thread_Cache在MySQL有幾個主要的參數,簡略引見以下:
thread_cache_size
Thread_Cache 中寄存的最年夜銜接線程數.在短銜接的運用中Thread_Cache的功能異常顯著,由於在運用中數據庫的銜接和創立長短常頻仍的,假如不應用 Thread_Cache那末消費的資本長短常可不雅的!在長銜接中固然帶來的改良沒有短銜接的那末顯著,然則利益是不言而喻的.但其實不是越年夜越好年夜了反而 糟蹋資本這個切實其實定普通以為和物理內存有必定關系,以下:
1G —> 8
2G —> 16
3G —> 32
>3G —> 64
假如短銜接多的話可以恰當加年夜.
thread_stack
每一個銜接被創立的時刻,mysql分派給它的內存.這個值普通以為默許便可以運用於年夜部門場景了,除非需要非則不要動它.
thread_handing
應用Thread_Cache處置銜接的方法,5.1.19添加的新特征.有兩個值可選[no-threads|one-thread-per-connection] 看字面意思年夜家也該猜出八九分了,呵呵,no-threads 辦事器應用一個線程,one-thread-per-connection 辦事器為每一個客戶端要求應用一個線程.原手冊中提到,no-threads是在Linux下調試用的.
mysql> show variables like 'thread%';
+——————-+—————————+
| Variable_name | Value |
+——————-+—————————+
| thread_cache_size | 32 |
| thread_handling | one-thread-per-connection |
| thread_stack | 196608 |
+——————-+—————————+
3 rows in set (0.01 sec)
mysql> show status like '%connections%';
+———————-+——–+
| Variable_name | Value |
+———————-+——–+
| Connections | 199156 |
| Max_used_connections | 31 |
+———————-+——–+
2 rows in set (0.00 sec)
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個敕令,可以看到辦事器的 thread_cache池中最多可以寄存32個銜接線程,為每一個客戶端球應用一個線程.為每一個銜接的線程分派192k的內存空間.
服 務器總共有199156次銜接,最年夜並發銜接數為31,以後在thread_cashe池中的銜接數為3個,銜接數為6個,處於活潑狀況的有5個,共創立 了8689次銜接.明顯這裡以短銜接為主.可以算出thread_cache射中率,公式為:
Thread_Cache_Hit=(Connections-Thread_created)/Connections*100%
以後辦事器的Thread_cache射中率約為95.6%這個成果我照樣比擬滿足的.然則可以看出 thread_cache_size有點過剩改成16或8更公道一些.
2、TABLE_CACHE(5.1.3及今後 版本別名TABLE_OPEN_CACHE)
因為MySQL是多線程的機制,為了進步機能,每一個線程都是單獨翻開本身須要的表的文件描 述符,而不是經由過程同享曾經翻開的.針對分歧存儲引擎處置的辦法固然也紛歧樣.
在myisam表引擎中,數據文件的描寫符 (descriptor)是不同享的,然則索引文件的描寫符倒是一切線程同享的.Innodb中和應用表空間類型有關,假設是同享表空間那末現實就一個數 據文件,固然占用的數據文件描寫符就會比自力表空間少.
小我感到有點像php外面的fopen翻開一個銜接,操作完數據以後,其實不立刻 封閉,而是緩存起來,期待下一個銜接這個文件的要求就不用去從新翻開文件了,不知樣懂得對纰謬,哈.
手冊上有段關於翻開表時的描寫:
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語句翻開一個表，將為該線程專門分派一個表。該表不被其它線程同享，只要線程挪用HANDLER tbl_name CLOSE或線程終止後才被封閉。表封閉後，被拉回表緩存中(假如緩存不滿)。
mysql手冊上給的建議年夜小 是:table_cache=max_connections*n
n表現查詢語句中最年夜表數, 還須要為暫時表和文件保存一些額定的文件描寫符。
這個數據遭到許多質疑,table_cache夠用就好,檢討 Opened_tables值,假如這個值很年夜,或增加很快那末你就得斟酌加年夜table_cache了.
鄙人面的前提下，未應用的表 將被封閉並從表緩存中移出：
當緩存滿了而且一個線程試圖翻開一個不在緩存中的表時。
當緩存包括跨越table_cache個條目，而且緩存中的表不再被任何線程應用。
當表刷新操作產生。當履行FLUSH TABLES語句或履行mysqladmin flush-tables或mysqladmin refresh敕令時會產生。
當表緩存滿時，辦事器應用以下進程找到一個緩存進口來應用：
以後未應用的表被釋放，以比來起碼應用次序。
假如緩存滿了而且沒有表可以釋放，然則一個新表須要翻開，緩存必需暫時被擴展。
假如緩存處於一個暫時擴展狀況而且一個表從在用變成不在用狀況，它被封閉並從緩存中釋放。
幾個關於table_cache的 狀況值:
1. table_cache：一切線程翻開的表的數量。增年夜該值可以增長mysqld須要的文件描寫符的數目。默許值是64.
2. open_tables：以後翻開的表的數目.
3. opened_tables ：Number of table cache misses，假如opened_tables較年夜，table_cache 值能夠太小.
4. Open_table_definitions : The number of cached .frm files. This variable was added in MySQL 5.1.3.
5. Opened_table_definitions : The number of .frm files that have been cached. This variable was added in MySQL 5.1.24.
