MySQL中table_cache優(yōu)化的示例分析

這篇文章主要介紹MySQL中table_cache優(yōu)化的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

table_cache指定表高速緩存的大小。每當(dāng)MySQL訪問(wèn)一個(gè)表時(shí)，如果在表緩沖區(qū)中還有空間，該表就被打開(kāi)并放入其中，這樣可以更快地訪問(wèn)表內(nèi)容。通過(guò)檢查峰值時(shí)間的狀態(tài)值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發(fā)現(xiàn)open_tables等于table_cache，并且opened_tables在不斷增長(zhǎng)，那么你就需要增加table_cache的值了（上述狀態(tài)值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設(shè)置成很大的值。如果設(shè)置得太高，可能會(huì)造成文件描述符不足，從而造成性能不穩(wěn)定或者連接失敗。

首先是MyISAM： 
從官方網(wǎng)站上面看，每個(gè)線程會(huì)獨(dú)自持有一個(gè)數(shù)據(jù)文件的文件描述符，而索引文件的文件描述符是公用的。當(dāng)table cache不夠用的時(shí)候，MySQL會(huì)采用LRU算法踢掉最長(zhǎng)時(shí)間沒(méi)有使用的表。如果table_cache設(shè)置過(guò)小，MySQL就會(huì)反復(fù)打開(kāi)、關(guān)閉 frm文件，造成一定的性能損失。那么，table_cache設(shè)置是不是越大越好呢？從table_cache negative scalability 這篇文章的測(cè)試可以看出，如果table_cache設(shè)置過(guò)大，MySQL將會(huì)消耗很多CPU去做 table cache的算法運(yùn)算（具體是哪個(gè)算法目前不清楚，有可能是LRU）。因此table_cache的值一定要設(shè)置合理，沒(méi)事多看一看 opened_tables參數(shù)，如果一直增長(zhǎng)的話，就需要適當(dāng)增加table_cache的值了。 
  
接著是InnoDB： 
InnoDB的元數(shù)據(jù)管理是放在共享表空間里面做的，所以獲取表的結(jié)構(gòu)不需要去反復(fù)解析frm文件，這是比MyISAM強(qiáng)的地方。即使 table_cache設(shè)置過(guò)小，對(duì)于InnoDB的影響也是很小的，因?yàn)樗静恍枰磸?fù)打開(kāi)、關(guān)閉frm文件去獲取元數(shù)據(jù)。  根據(jù)How innodb_open_files affects performance這篇文章的測(cè)試可以看出，table_cache和  innodb_open_files的大小對(duì)InnoDB效率的影響比較小。但是在InnoDB crash的情況下， innodb_open_files設(shè)置過(guò)小會(huì)影響recovery的效率。所以用InnoDB的時(shí)候還是把 innodb_open_files放大一些比較合適。

以上是“MySQL中table_cache優(yōu)化的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！