table_open_cache不优化元数据访问，因其仅缓存表文件句柄（.frm/.ibd），而MySQL 8.0+的数据字典由InnoDB常驻内存管理；真正影响元数据缓存的是table_definition_cache参数。
table_open_cache 不减少元数据访问开销，它只缓存表文件句柄，不是元数据缓存机制。
为什么调大 table_open_cache 对元数据没用
MySQL 8.0+ 的数据字典（表结构、列定义、约束等）由 InnoDB 管理并常驻内存，不走 table_open_cache；它缓存的是操作系统级的文件描述符（.frm、.ibd），用于复用已打开的表物理文件。元数据访问慢，大概率是 table_definition_cache 不足、或查询了 information_schema 这类需动态扫描的视图。
-
table_open_cache影响的是“打开表文件”这个系统调用频次，不是“读取表结构”的内存查找 - 若
SHOW STATUS LIKE 'Opened_tables'持续飙升，说明句柄复用失败——这是文件 I/O 开销，不是元数据解析开销 - 查
information_schema.TABLES慢，和table_open_cache几乎无关；那是 metadata lock + 全量扫描逻辑，应避免在生产环境直接查该库
真正影响元数据访问的参数是 table_definition_cache
这个参数才负责缓存表定义（如 .frm 内容或数据字典快照），尤其对 MyISAM 或混合引擎场景明显；InnoDB 8.0+ 虽有内置字典，但部分操作（如 SHOW CREATE TABLE）仍会参考该缓存。
- 设太小 → 每次访问表结构都要重新读磁盘或解析字典，表现为
Open_table_definitions持续增长（需SHOW GLOBAL STATUS LIKE 'Open_table_definitions'查） - 合理值 ≈ 实际表总数 × 1.2～1.5，上限建议不超过 4000；例如有 1200 张表，设
table_definition_cache = 1600更稳 - 它不消耗文件描述符，但占用内存；过大会导致内存碎片，尤其在表数波动大的环境
哪些现象误判成“元数据开销”，实际是 table_open_cache 问题
表面像元数据慢，实则是文件句柄反复打开引发的连锁反应：
-
SHOW PROCESSLIST中大量线程卡在opening table状态 —— 这是table_open_cache不足的典型信号 - 错误日志出现
Can't open file: './db/t1.frm' (errno: 24)—— 文件描述符耗尽，根源常是table_open_cache设得太大但open_files_limit没同步扩 -
Open_tables长期接近table_open_cache值，且Opened_tables每秒增 >10 —— 缓存淘汰太频繁，物理文件反复 open/close
调参前必须确认的三件事
别改配置，先跑这几条命令：
- 查真实瓶颈：
SHOW GLOBAL STATUS LIKE 'open%tables%'—— 看Open_tables和Opened_tables比值是否 - 查系统限制：
SHOW VARIABLES LIKE 'open_files_limit'—— 若小于你打算设的table_open_cache，改了也白改 - 查并发压力：
SHOW VARIABLES LIKE 'max_connections'和SHOW GLOBAL STATUS LIKE 'Threads_connected'—— 如果活跃连接远低于max_connections，按连接数倍数算缓存值就是误导
真正要压低元数据访问延迟，优先检查应用是否高频执行 DESCRIBE、SHOW COLUMNS 或遍历 information_schema；这些行为本身比参数调优更值得优化。
