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是原子的「插入或更新」，只持有一组记录锁，且不会删除原行，锁粒度更可控。
示例对比：
-- 危险：REPLACE 可能锁住整个唯一索引范围 REPLACE INTO users (id, name, updated_at) VALUES (123, 'Alice', NOW()); <p>-- 推荐：锁更精准，且支持部分字段更新 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。
