大量线程卡在opening tables状态是table_open_cache不足的直接信号；需检查open_tables是否等于table_open_cache、opened_tables每秒增量是否超50，并同步调优table_open_cache_instances至8～16以降低锁争用。
show processlist里大量线程卡在opening tables状态
这是最直接的信号。一旦看到几十甚至上百个线程长时间停留在 opening tables 或 closing tables 状态，基本可以锁定是表缓存不足——MySQL被迫频繁打开/关闭物理表文件，而不是复用缓存中的句柄。
此时不要急着调参，先确认是否真由 table_open_cache 引起：
- 执行
SHOW VARIABLES LIKE 'table_open_cache';，看当前值是否明显偏低（如默认 64 或 512） - 执行
SHOW GLOBAL STATUS LIKE 'Open%tables';，重点比对Open_tables和table_open_cache：若两者相等，说明缓存已满，新请求只能淘汰旧项或绕过缓存 - 检查业务表总数：如果库中有 800 张表，而
table_open_cache只设了 512，且并发连接中平均每个查询涉及 3 张表，那大概率不够用
Opened_tables 每秒增长超 50 就该警惕
Opened_tables 是累计值，单看绝对值没意义；关键是它的**增量速率**。间隔 10 秒执行两次 SHOW GLOBAL STATUS LIKE 'Opened_tables';，差值 > 50 就说明 MySQL 每秒都在打开新表文件，I/O 和锁开销陡增。
这个现象常出现在多表 JOIN 场景（比如 5 张表关联），因为每个连接打开的表数 = JOIN 表数量 × 并发活跃连接比例。容易被忽略的是：
-
Opened_tables上涨快 ≠ 表太多，而是「缓存没兜住活跃访问模式」 - MyISAM 表每张占 2 个文件描述符（数据 + 索引），InnoDB 通常只占 1 个（
.ibd），混用引擎时要按类型分别估算 - 必须同步检查
open_files_limit：它得 ≥table_open_cache× 1.2，否则调大后反而触发 OS 层文件描述符耗尽
调整 table_open_cache_instances 降低锁争用
MySQL 5.7 默认把整个表缓存放在一个全局哈希结构里，高并发下所有线程抢同一把锁。即使你把 table_open_cache 调到 2048，若 table_open_cache_instances 还是 1 或 8，依然会卡在 opening tables。
实操建议：
- 将
table_open_cache_instances设为 8～16（偶数），让缓存分片，减少锁冲突 - 调整后观察
SHOW PROCESSLIST中opening tables状态线程是否快速回落 - 别盲目设成 128：实例内存有限时，过多分片反而增加管理开销；8～16 已能覆盖多数 500 并发以内的场景
验证是否真的生效，只看 Opened_tables 增速和比值
调完参数别只看 Open_tables 变多了就以为好了。真正有效的指标是：
-
Opened_tables的 10 秒增量从 60+ 降到 5 以内 -
Open_tables / Opened_tables ≥ 0.85：表示 85% 的表打开请求命中缓存 -
Open_tables / table_open_cache ≤ 0.95：说明缓存有余量，未长期满载
最容易被忽略的一点：这些比值必须在**业务高峰时段持续观测 5～10 分钟**。低峰期看着正常，一到下单或报表生成时段又崩，说明预估的并发活跃表数还是偏低。
