bitscn.com 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放大一些比较合适。 bitscn.com