共计 1165 个字符，预计需要花费 3 分钟才能阅读完成。

这篇文章主要介绍 MySQL 中 table_cache 优化的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

table_cache 指定表高速缓存的大小。每当 MySQL 访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。通过检查峰值时间的状态值 Open_tables 和 Opened_tables，可以决定是否需要增加 table_cache 的值。如果你发现 open_tables 等于 table_cache，并且 opened_tables 在不断增长，那么你就需要增加 table_cache 的值了（上述状态值可以使用 SHOW STATUS LIKE‘Open%tables’获得）。注意，不能盲目地把 table_cache 设置成很大的值。如果设置得太高，可能会造成文件描述符不足，从而造成性能不稳定或者连接失败。

首先是 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 放大一些比较合适。

以上是“MySQL 中 table_cache 优化的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注丸趣 TV 行业资讯频道！