MySQL多线程事务卡在Waiting for table metadata lock是因DDL与DML争抢MDL锁，长事务未提交会阻塞后续所有需该表写锁的操作；innodb_lock_wait_timeout不适用于MDL锁；应主动识别并终止长事务，优先使用INSERT...ON DUPLICATE KEY UPDATE替代REPLACE INTO，并用pt-osc或gh-ost实现无锁DDL。
MySQL 多线程事务为什么会卡在 Waiting for table metadata lock
这不是行锁或间隙锁的问题，而是 DDL 操作（如 ALTER TABLE、DROP INDEX）与并发 DML 事务争抢元数据锁（MDL）导致的。只要有一个长事务没提交，后续所有需要该表 MDL 写锁的操作（包括另一个事务里的 SELECT 在某些隔离级别下）都会被阻塞。
典型现象：
SHOW PROCESSLIST;中看到一堆线程状态为
Waiting for table metadata lock，且 Time 值持续增长；而 information_schema.INNODB_TRX 里可能只有一两个活跃事务，但它们持有 MDL 锁时间远超预期。
- 根本原因：MySQL 5.5+ 引入 MDL，自动加锁，无法绕过；
START TRANSACTION后首次访问表即加 MDL 读锁，直到事务结束才释放 - 高危操作：
ALTER TABLE ... ALGORITHM=INPLACE仍需短暂写锁；OPTIMIZE TABLE、ANALYZE TABLE也会触发 MDL 写锁 - 排查命令：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table';
innodb_lock_wait_timeout 对多线程事务死锁没用
这个参数只控制「行锁等待超时」，不适用于 MDL 锁、表级锁或死锁检测失败后的挂起状态。MySQL 的死锁检测器（innodb_deadlock_detect）默认开启，但它只对 InnoDB 行锁有效；一旦涉及 MDL 或跨引擎（如 MyISAM + InnoDB），死锁就无法自动发现，只能靠超时或人工干预。
-
innodb_lock_wait_timeout默认 50 秒，仅作用于UPDATE/DELETE/INSERT ... SELECT等等待行锁的场景 - MDL 等待无超时机制（除非客户端主动断开或
lock_wait_timeout被设为非 0 值——注意这是会话级变量，不是全局配置） - 真正有效的应对是：提前识别长事务（
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - TRX_STARTED) > 60），并限制其生命周期
批量写入时用 INSERT ... ON DUPLICATE KEY UPDATE 替代 REPLACE INTO
REPLACE INTO 实际是「DELETE + INSERT」，会触发两次行锁 + 一次自增 ID 跳变 + 可能的外键级联操作，在多线程高并发下极易引发锁升级和间隙锁冲突；而 INSERT ... ON DUPLICATE KEY UPDATE 是原子的「插入或更新」，只持有一组记录锁，且不会删除原行，锁粒度更可控。
齐博B2B系统是一款基于PHP程序和Mysql数据库为基础的开源B2B行业门户电子商务网站建站系统， 系统代码完整、开源，功能全面，架构优秀，提供良好的用户体验、及管理平台，是目前搭建B2B行业门户网站最好的程序之一。齐博B2B具有的功能特点包括：通行证整合功能通过通行证的整合，可以与流行的PHPWIND论坛或Discuz论坛以及Ucenter中心等进行通讯，从而为用户提供更多的交流场所，增加网站
示例对比：
-- 危险：REPLACE 可能锁住整个唯一索引范围 REPLACE INTO users (id, name, updated_at) VALUES (123, 'Alice', NOW());-- 推荐：锁更精准，且支持部分字段更新 INSERT INTO users (id, name, updated_at) VALUES (123, 'Alice', NOW()) ON DUPLICATE KEY UPDATE name = VALUES(name), updated_at = VALUES(updated_at);
- 确保
ON DUPLICATE KEY UPDATE中的WHERE条件命中的是唯一索引（主键或 UNIQUE KEY），否则会退化为全表扫描加锁 - 避免在
UPDATE子句中引用未在VALUES()中提供的列，否则可能产生不可预期的 NULL 覆盖 - 如果业务允许，考虑用
INSERT IGNORE配合应用层重试，进一步降低锁持有时间
用 pt-osc 或 gh-ost 替代原生 ALTER TABLE
原生 ALTER TABLE 在 MySQL 5.6+ 支持 ALGORITHM=INPLACE，但仍需在开始和结束阶段获取 MDL 写锁，对大表来说这两段“短锁”也可能卡住几十秒以上的 DML 流量。而 pt-online-schema-change（Percona Toolkit）和 gh-ost（GitHub 开源）通过影子表 + 触发器/二进制日志解析实现无锁变更，真正把锁影响降到最低。
-
pt-osc依赖触发器，不兼容有大量触发器或禁用触发器的环境；gh-ost基于 binlog，无需触发器，但要求 binlog_format = ROW 且主从延迟可控 - 二者都不修改原表结构，变更期间原表持续可读写；但要注意
gh-ost的 cut-over 阶段仍有毫秒级写入中断（可通过--max-load和--critical-load控制） - 务必在低峰期执行，并监控
show processlist中是否有copying to tmp table类型长时间运行（说明工具内部拷贝卡住）
MDL 锁和事务生命周期绑定得比大多数人想的更紧，一个没显式 COMMIT 的事务，哪怕只执行了一条 SELECT，也可能让后续所有 DDL 和部分 DML 彻底停摆。别迷信“我只是查一下”，先看 TRX_STATE 和 TRX_STARTED。
