值得调，但需精准而非盲目调高；它仅缓存表句柄和元数据，不缓存数据或索引，真正影响查询性能的是innodb_buffer_pool_size。
MySQL 8.0 的 table_open_cache 还值得调吗？
不值得盲目调高。MySQL 8.0 中 table_open_cache 的作用已大幅弱化，它只缓存表的**打开句柄（file descriptor）和元数据结构体**，不缓存数据或索引——真正影响查询性能的是 innodb_buffer_pool_size，不是这个参数。
常见误判：看到 Opened_tables 持续上升，就以为“缓存不够”，立刻加 table_open_cache。实际上，只要 Open_tables 稳定在 table_open_cache 附近（比如 95% 以上），说明当前值已够用；Opened_tables 上升只是业务 SQL 打开新表的自然行为，尤其 ORM 动态拼表、分区表轮转、临时表多时更明显。
哪些场景才真需要调 table_open_cache？
只有两类情况需关注：
- 系统报错
Too many open files，且ulimit -n和fs.file-max已调高，但mysql -e "SHOW GLOBAL STATUS LIKE 'Open_tables';"接近table_open_cache值 → 表明句柄真的不够用 - 频繁执行
FLUSH TABLES或大量DROP/CREATE TEMPORARY TABLE，导致句柄反复释放重建，Table_open_cache_overflows显著增长（每秒 > 1）
注意：table_open_cache 不是越大越好。它每项占用约 2–3KB 内存（含内部结构），设为 4000 就额外吃掉 ~10MB；更重要的是，过高会加剧 LOCK_open 全局锁争用，反而拖慢高并发建表/删表操作。
table_open_cache 怎么设才合理？
别拍脑袋，按实际负载算：
- 先查当前峰值：
mysql -e "SHOW GLOBAL STATUS LIKE 'Open_tables';"和SHOW GLOBAL STATUS LIKE 'Opened_tables';"，观察 5–10 分钟内最大Open_tables - 保守值 = 观测到的最大
Open_tables× 1.3（留缓冲），但上限建议 ≤ 4000（除非你有超多分区表或微服务共用实例） - 必须同步检查并匹配系统限制：
cat /proc/sys/fs/file-max和ulimit -n，确保两者都 ≥table_open_cache× 2（MySQL 内部还需额外句柄） - 配置后重启，立刻验证是否生效：
mysql -e "SHOW VARIABLES LIKE 'table_open_cache';"，值必须和 my.cnf 里写的完全一致
示例：观测到 Open_tables 最高 1280，则设 table_open_cache = 1664（1280×1.3 向上取整到 64 的倍数），而非直接写 2048 或 4000。
比调 table_open_cache 更有效的替代动作
绝大多数性能问题根源不在这里：
- 关闭不必要的表扫描：检查慢日志中
type: ALL的语句，加索引或改写 SQL，减少每次查询打开的表数量 - 清理冗余表和视图：特别是测试环境残留的临时表、废弃的分区表，它们持续占用 cache slot
- 避免在存储过程中反复
CREATE TEMPORARY TABLE：改用内存表或 WITH 子句，减少句柄生命周期管理开销 - 确认没误用
table_definition_cache：它缓存的是 .frm 或数据字典元数据，和table_open_cache是两回事；若Table_definition_cache不足，会报Can't open table而非Too many open files
真正容易被忽略的是：MySQL 8.0 默认启用 performance_schema，它自身会打开大量内部表（如 events_statements_history_long），这些也计入 table_open_cache 统计。如果没关掉不用的 instruments，Opened_tables 高可能根本不是业务 SQL 导致的。
