mysql卡在opening tables状态大概率因table_open_cache过小或mdl锁阻塞：前者导致频繁重开表、io升高，后者使所有访问该表的请求集体挂起；需结合open_tables/opened_tables比值、innodb_trx及performance_schema锁等待链综合诊断。
MySQL卡在Opening tables状态，大概率不是SQL本身慢，而是表缓存不足或元数据锁（MDL）被阻塞——前者影响并发打开效率，后者会直接让所有访问该表的请求集体挂起。
table_open_cache设置过小导致频繁重开表
当并发连接数高、SQL涉及多表JOIN或大量库表切换时，MySQL需要为每个线程单独打开并缓存表结构。如果table_open_cache值太小，就会反复淘汰旧表、重新打开新表，每次打开都触发磁盘IO和元数据读取，表现就是大量线程卡在Opening tables状态。
- 检查当前配置：
SHOW VARIABLES LIKE 'table_open_cache';，再对比SHOW STATUS LIKE 'Open_tables';和Opened_tables；若Opened_tables持续增长且远大于Open_tables，说明缓存命中率低 - 经验值：设为
max_connections × 平均每条SQL涉及的表数 × 2，例如200连接、平均查5张表，建议从2000起步 - 注意系统限制：
table_open_cache过高可能耗尽操作系统文件描述符，需同步调大/proc/sys/fs/file-max和ulimit -n
MDL锁被长事务或失败查询隐式持有
哪怕只是执行一条SELECT ... FOR UPDATE没提交，或一个查询因字段不存在而报错后事务未显式COMMIT/ROLLBACK，都会让该表的MDL锁一直不释放。后续任何DDL、DML甚至普通SELECT都得等，状态统一显示为Opening tables——这不是在“打开”，是在“等锁”。
- 查活跃事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60; - 查隐性锁持有者：
SELECT THREAD_ID, OBJECT_NAME FROM performance_schema.data_locks WHERE LOCK_DATA IS NULL AND OBJECT_SCHEMA = 'your_db';（LOCK_DATA IS NULL常表示MDL级等待） - 别只看
SHOW PROCESSLIST里的State，Info为空、Time超长的连接更可疑
主从复制场景下SQL线程卡在Opening tables
从库SQL线程回放主库日志时，若遇到DDL（如ALTER TABLE），必须获取排他MDL锁。一旦它卡住，不仅自身停在Opening tables，还会导致所有新连接对该表的操作全部排队，现象是整个实例“突然变慢”，但SHOW SLAVE STATUS里Seconds_Behind_Master未必立刻飙升。
- 确认是否为复制线程：
SHOW PROCESSLIST中User列为system user、Command为Connect、State为Opening tables的那条 - 不要直接
KILL那个线程——它大概率是受害者；优先查sys.schema_table_lock_waits或手动关联performance_schema.data_lock_waits找真正持锁的THREAD_ID - 临时缓解可设
slave_parallel_workers = 4（5.7+）分摊单线程压力，但治标不治本
真正难处理的从来不是“怎么调参”，而是那些没报错、没阻塞语句、INNODB_TRX里也看不到的隐形事务——它们可能就卡在一个没提交的START TRANSACTION后面，安静地锁着整张表。定位这类问题，靠的不是SHOW PROCESSLIST，而是performance_schema里锁等待链的完整回溯。
