table_open_cache实际生效值受open_files_limit截断，配4000但open_files_limit为2048时真实值即为2048；需同步查三组值，并确保Open_tables/table_open_cache长期处于0.7–0.95区间。
table_open_cache 实际生效值为什么总是比配置的小？
MySQL 启动时会把 table_open_cache 截断到 open_files_limit 以内，且不报错。你配了 4000，但系统级 open_files_limit 是 2048，真实值就是 2048 —— 这是绝大多数“调了没用”的根本原因。
必须一次性查清三组值：
SHOW VARIABLES LIKE 'table_open_cache';SHOW VARIABLES LIKE 'open_files_limit';-
SHOW GLOBAL STATUS LIKE 'Open%tables';（重点看Open_tables和Opened_tables）
如果 Open_tables / table_open_cache 长期 > 0.95，说明缓存常满、频繁淘汰；如果长期
my.cnf 里只写 table_open_cache = 2048 不够
单独调大 table_open_cache 在高并发下几乎无效，因为默认 table_open_cache_instances = 1，所有线程抢同一把 mutex，你会在 SHOW ENGINE INNODB STATUS 里看到大量线程卡在 Opening tables 状态。
必须同步设置关联参数：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
table_open_cache = 2048（4G 内存机器常见起点） -
table_open_cache_instances = 8（设为物理 CPU 核数，上限 16） -
open_files_limit = 4096（必须 ≥table_open_cache × 1.25，否则前两项白配）
注意：table_open_cache_instances 和 table_open_cache 是分片关系，不是乘积容量；分片后锁竞争下降明显，但总缓存条目上限仍是 table_open_cache。
别按 max_connections × 表数量硬算
这个公式在 OLTP 场景下严重高估。一个连接平均打开 2 张表，1000 连接就配 2000？实际生产中峰值 Open_tables 可能只有 600 —— 因为连接复用表缓存、临时表/日志/复制线程也要抢文件描述符、InnoDB 的 LRU 淘汰策略会让冷表很快被踢出。
更靠谱的做法是：
- 压测或观察生产高峰 1 小时内的
Opened_tables增量 - 取最大值，再加 20% —— 这才是你要设的
table_open_cache下限 - 4G 内存 + 几十张表 + 低并发，
512更稳；盲目拉到 4000 可能触发系统级ulimit -n限制，MySQL 启动时静默降级
云数据库 RDS/PolarDB 能不能手动改？
不能。RDS、PolarDB 这类云服务通常已自动调优 table_open_cache 和 table_open_cache_instances，你手动改反而可能触发平台保护机制回滚。但自建 MySQL 必须显式配置，尤其要注意 Linux 系统级限制：ulimit -n 若低于 open_files_limit，MySQL 启动时会静默降级 —— 这个细节最容易被忽略，也最难排查。
