长事务会阻塞ALTER TABLE，因其持有MDL读锁直至提交，导致DDL等待表元数据锁；需通过INNODB_TRX定位并KILL异常长事务，INSTANT仅支持特定轻量变更且受限于表格式与版本。
长事务为什么会让 ALTER TABLE 卡住
MySQL（尤其是 InnoDB）在执行 ALTER TABLE 时，多数情况下需要获取表的 SX（Shared-Exclusive）锁或 X（Exclusive）锁。只要有一个活跃事务正在访问该表（哪怕只是 SELECT），且事务还没提交，DDL 就会排队等待——不是等语句执行完，而是等整个事务结束。常见现象是 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虽能绕过锁表，但它们本身也会探测并规避长事务——如果发现有活跃事务超过阈值，会直接退出
如何快速定位并终止干扰事务
别靠猜。先查谁在占着表，再决定是否干掉它。重点看 TRX_STARTED 时间和 TRX_STATE，而不是只盯 TRX_QUERY。
SELECT trx_id, trx_started, trx_state, trx_mysql_thread_id, SUBSTRING_INDEX(trx_query, ' ', 4) AS short_query FROM information_schema.INNODB_TRX WHERE trx_started < DATE_SUB(NOW(), INTERVAL 60 SECOND) ORDER BY trx_started;
- 用
trx_started 过滤“明显异常”的长事务（可根据业务调整为 30s 或 5m） -
trx_state = 'RUNNING'未必安全——它可能刚执行完一条语句，但事务还开着；真正要看的是trx_started时间戳 - 确认无误后，用
KILL <thread_id></thread_id>终止，不是KILL QUERY（后者只杀当前语句，事务仍存活） - 避免在高峰期对核心业务线程执行
KILL，优先联系对应服务 owner 共同判断
ALTER TABLE 加上 ALGORITHM=INSTANT 真的不锁表吗
只对极少数变更有效：ADD COLUMN（末尾）、DROP COLUMN（非主键/索引列）、RENAME COLUMN、CHANGE COLUMN（仅改注释）。而且必须满足：表格式是 Dynamic 或 Compressed，MySQL 版本 ≥ 8.0.12，且没有全文索引、空间索引、生成列依赖该字段。
-
ADD COLUMN加在中间位置？不支持INSTANT，自动退化为COPY或INPLACE，仍需锁表 -
MODIFY COLUMN改类型（如VARCHAR(100)→VARCHAR(200)）在 8.0.29+ 支持INSTANT，但改成TEXT或加NOT NULL默认值就不行 - 执行前务必检查
SHOW CREATE TABLE输出里的ROW_FORMAT，如果是Redundant或Compact，INSTANT直接报错 - 即便支持
INSTANT，也要注意 binlog 记录方式变化：它写的是“元数据变更”，从库回放时若版本不一致，可能失败
线上 DDL 变更前必须做的三件事
DDL 不是“跑一下就完事”，它是数据库最危险的操作之一。没做这三步，等于裸奔。
- 在从库或影子库上用真实数据量压测完整流程，观察
INFORMATION_SCHEMA.INNODB_METRICS中的dml_reads、dml_writes是否突增，以及磁盘 IO 峰值 - 检查
innodb_lock_wait_timeout和lock_wait_timeout设置——默认 50 秒，如果 DDL 等锁超时，会报Lock wait timeout exceeded，但事务可能已部分执行（如已建临时表），导致残留状态 - 确保
binlog_format = ROW，且从库开启了slave_parallel_workers > 0；否则 DDL 在从库串行回放，可能拖慢复制，甚至因锁冲突卡死
真正麻烦的从来不是语法对不对，而是事务边界模糊、锁等待链隐藏得深、还有人把 DDL 当成低风险操作去凌晨三点手动执行。
