如何通过优化MySQL长事务管理，减少其对DDL操作的影响？

本文共计1165个文字，预计阅读时间需要5分钟。

MySQL（尤其是InnoDB）在执行ALTER TABLE时，在多种情况下需要获取表的SX（共享-独占）锁或X（独占）锁。只有当一个活跃的事务正在访问该表（例如，正在执行SELECT操作）且尚未提交，DDL操作（如ALTER TABLE）就会排队等待——这不是等待语句执行完毕，而是等待整个事务结束。

常见现象是，使用SHOW PROCESSLIST查看时，会看到ALTER TABLE操作处于Waiting for table metadata lock状态。

根本原因不是“查询慢”，而是事务生命周期太长：比如应用层开了事务但忘了 COMMIT，或用 ORM 自动开启长事务处理批量逻辑，又或者监控脚本跑了几十分钟的 SELECT ... FOR UPDATE。

• 显式事务中未提交的 SELECT、INSERT、UPDATE 都会持有 MDL（Metadata Lock）读锁，阻塞 DDL 写锁
• READ-COMMITTED 隔离级别下，普通 SELECT 不加锁，但事务一旦开始（BEGIN），后续所有语句都在同一事务上下文中，MDL 锁持续到 COMMIT
• Percona Toolkit 的 pt-online-schema-change 或 gh-ost 虽能绕过锁表，但它们本身也会探测并规避长事务——如果发现有活跃事务超过阈值，会直接退出

如何快速定位并终止干扰事务

别靠猜。先查谁在占着表，再决定是否干掉它。