table_cache指定表高速緩存的大小。每當MySQL訪問一個表時，如果在表緩沖區中還有空間，該表就被打開並放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發現open_tables等於table_cache，並且opened_tables在不斷增長，那麼你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設置成很大的值。如果設置得太高，可能會造成文件描述符不足，從而造成性能不穩定或者連接失敗。
www.itcankao.cn
首先是MyISAM：
從官方網站上面看，每個線程會獨自持有一個數據文件的文件描述符，而索引文件的文件描述符是公用的。當table cache不夠用的時候，MySQL會采用LRU算法踢掉最長時間沒有使用的表。如果table_cache設置過小，MySQL就會反復打開、關閉 frm文件，造成一定的性能損失。那麼，table_cache設置是不是越大越好呢？從table_cache negative scalability 這篇文章的測試可以看出，如果table_cache設置過大，MySQL將會消耗很多CPU去做 table cache的算法運算（具體是哪個算法目前不清楚，有可能是LRU）。因此table_cache的值一定要設置合理，沒事多看一看 opened_tables參數，如果一直增長的話，就需要適當增加table_cache的值了。
接著是InnoDB：
InnoDB的元數據管理是放在共享表空間裡面做的，所以獲取表的結構不需要去反復解析frm文件，這是比MyISAM強的地方。即使 table_cache設置過小，對於InnoDB的影響也是很小的，因為它根本不需要反復打開、關閉frm文件去獲取元數據。 根據How innodb_open_files affects performance這篇文章的測試可以看出，table_cache和 innodb_open_files的大小對InnoDB效率的影響比較小。但是在InnoDB crash的情況下， innodb_open_files設置過小會影響recovery的效率。所以用InnoDB的時候還是把 innodb_open_files放大一些比較合適。
