判断table_open_cache是否真不够用：Open_tables接近其值且Opened_tables每秒增超50，才是典型信号；若Open_tables很小但Opened_tables达百万级，则多因频繁建临时表或DROP/CREATE操作，非缓存不足。
怎么判断table_open_cache真不够用了
别一看到查询慢就改这个参数。先确认是不是它的问题：Open_tables接近table_open_cache值，同时Opened_tables每秒涨几十甚至上百，才是典型信号。执行两次SHOW GLOBAL STATUS LIKE 'Opened_tables'，间隔10秒，差值＞50就基本坐实了。如果Open_tables才一两百，但Opened_tables已经几百万，那大概率是SQL里频繁建临时表或反复DROP/CREATE TABLE，不是缓存大小的事。
设多大才算安全又有效
不能套“max_connections × 表数量”这种公式硬算——OLTP场景下会严重高估。更靠谱的做法是：观察高峰期的Open_tables峰值，再加20%余量。比如峰值是320，就设成400。还要盯住硬约束：table_open_cache必须 ≤ open_files_limit，否则多余部分直接失效。查当前限制用SHOW VARIABLES LIKE 'open_files_limit'，建议留至少20%余量给日志、临时文件等。
- 4G内存机器，
table_open_cache=2048是常见起点；但如果你只有几十张表、并发也不高，设成512反而更稳 - 盲目设到2000+可能触发系统级错误
errno: 24 - Too many open files，MySQL会静默降级，Opened_tables照涨不误 - 调完后关键看
Open_tables / table_open_cache是否稳定在0.7～0.95之间——太低浪费内存，太高说明缓存快满，淘汰压力大
为什么调大了性能没提升？别漏了table_open_cache_instances
这个参数常被忽略，但在高并发下比table_open_cache本身还关键。默认是1，所有线程抢同一把锁，SHOW ENGINE INNODB STATUS里能看到大量wait array slots等待。它和table_open_cache是乘积关系：总缓存容量 = table_open_cache × table_open_cache_instances。建议设为CPU核心数（不超过16），8核机器就设8。
- RDS或云MySQL通常已自动调优，自建库务必检查
- 设太小会导致锁争用，哪怕
table_open_cache很大也白搭 - 设太大（比如32）反而增加管理开销，无实际收益
调完必须验证的两个指标
真正有效的阈值，不是Open_tables变多了，而是Opened_tables增速明显下降。重点盯两个比值：Open_tables / Opened_tables ≥ 0.85（反映缓存命中率），以及Open_tables / table_open_cache ≤ 0.95（反映缓存使用水位）。这两个数都得一起看——只看一个容易误判。另外，Linux下用lsof -u mysql | wc -l实时查mysqld进程打开的文件数，避免无限逼近系统limit。
