调大 metadata_locks_hash_instances 几乎没用，因它只优化锁查找速度，不解决锁争用本质；真正瓶颈在于DDL与长查询对同一表的MDL冲突。
为什么调大 metadata_locks_hash_instances 几乎没用
这个参数控制 MDL（元数据锁）哈希表的分桶数量，理论上能降低哈希冲突、提升锁查找效率。但实际中，它**不缓解锁争用本身**，只影响“查锁快不快”。真正卡住业务的，是 DDL 操作（如 ALTER TABLE）和长查询对同一张表的 MDL 冲突——哪怕哈希表再宽，锁还是得排队等。MySQL 5.7+ 默认值 256 已足够覆盖绝大多数中小规模实例；盲目调到 1024 或更高，不仅无效，还多占内存，且无法解决根本问题：谁在持锁、谁在等、为什么等不了。
真正有效的元数据锁争用排查路径
别先改参数，先定位瓶颈点：
-
SELECT * FROM performance_schema.metadata_locks查当前所有 MDL 持有与等待状态，重点关注LOCK_STATUS = 'PENDING'的行及其OWNER_THREAD_ID - 关联
performance_schema.threads找出等待线程对应的 SQL 和连接信息 - 用
SHOW PROCESSLIST或SELECT * FROM information_schema.PROCESSLIST看哪些连接处于Waiting for table metadata lock状态，并检查它们的TIME字段是否持续增长 - 特别注意那些执行时间长的
SELECT（尤其带LIMIT不足或未加索引的慢查询），它们会一直持有共享 MDL，阻塞后续 DDL
高频触发元数据锁阻塞的典型场景及对策
以下操作看似轻量，实则极易引发 MDL 队列雪崩：
-
ALTER TABLE t ADD COLUMN x INT：必须等所有对该表的活跃查询（包括只读）结束才能获取排他 MDL。对策：避开业务高峰；用pt-online-schema-change或gh-ost在线改表 - 长事务中执行
SELECT后，另一会话立刻发起ALTER TABLE：前者虽未修改数据，但事务未提交就一直持有 S 锁，后者卡在 X 锁请求上。对策：应用层严格控制事务边界，禁止在事务里做非 DB 操作 - 监控脚本频繁执行
SELECT COUNT(*) FROM t（无索引、全表扫描）：每次执行都持 S 锁数秒，叠加并发后形成 MDL 等待链。对策：改用近似统计（information_schema.TABLES中的TABLE_ROWS）、或加覆盖索引+快速 LIMIT -
DROP TABLE或TRUNCATE TABLE被阻塞：往往是因为有隐式打开的游标、未关闭的预处理语句，或从库延迟导致主库不敢释放锁。对策：检查SHOW OPEN TABLES WHERE In_use > 0
可安全调整、但需配合监控的参数
除了 metadata_locks_hash_instances，还有几个参数值得留意，但必须带验证：
-
lock_wait_timeout：仅控制 DML 等待 MDL 的超时（默认 31536000 秒），不是锁本身；调小只会让报错更快，不减少争用 -
max_connections：过高可能导致更多并发 MDL 请求，但过低又会压垮连接池；建议结合Threads_running监控动态伸缩 -
table_open_cache：若该值太小，频繁打开/关闭表会加剧 MDL 获取开销；应确保其 ≥ 并发访问的不同表数量 × 1.5
真正容易被忽略的是：MDL 阻塞往往不是孤立事件，而是由一个慢查询 + 一次 DDL + 一批等待 DML 共同构成的连锁反应。盯住第一个持锁不放的查询，比调任何参数都管用。
