MySQL 8.0 执行 ALTER TABLE 报 Lock wait timeout 通常是元数据锁（MDL）冲突，需查询 sys.schema_table_lock_waits 找到阻塞会话并终止或等待。
先说结论：该报错由元数据锁等待超时引起，核心是找出持有锁的事务并结束它。
- 先确认：查询 sys.schema_table_lock_waits 视图定位阻塞线程 ID。
- 先处理：评估业务影响后执行 KILL 命令终止阻塞会话。
- 再验证：重新执行 ALTER TABLE 语句确认锁等待消失。
命令速用版
直接复制以下 SQL 查询阻塞源，替换 schema 和 table 名称：
SELECT * FROM sys.schema_table_lock_waits WHERE object_schema = '数据库名' AND object_name = '表名';
获取 blocking_thread_id 后执行：
KILL <blocking_thread_id>;
为什么会这样
ALTER TABLE 需要获取元数据独占锁，而未提交的事务持有元数据共享锁。
MySQL 8.0 中 DDL 操作会请求元数据锁（MDL），如果存在未提交的事务（包括空闲事务）正在访问该表，DDL 必须等待这些事务释放锁。当等待时间超过 lock_wait_timeout 设定值，就会报错。
分步处理
1. 检查 performance_schema 状态：确认 performance_schema 已开启，否则 sys 视图不可用。
2. 查询锁等待视图：使用 sys.schema_table_lock_waits 查看具体阻塞线程。
3. 分析阻塞语句：关联 information_schema.processlist 查看阻塞线程正在执行的 SQL。
4. 终止或等待：若为长时间空闲事务可 KILL，若为关键业务需协调提交。
5. 重试 DDL：阻塞解除后重新执行 ALTER TABLE。
怎么验证是否生效
执行 ALTER TABLE 不再报错，且通过 SHOW WARNINGS 无 Lock wait 相关提示。
查询 sys.schema_table_lock_waits 确认该表无等待记录。
常见坑
1. 误杀系统线程：KILL 前确认 THREAD_ID 属于业务会话而非系统后台。
2. 事务回滚耗时：KILL 大事务可能触发回滚，期间锁仍未释放，需等待回滚完成。
3. 隐式事务：未显式 BEGIN 但执行了 DML 未 COMMIT 的会话也会持锁。
常见问题
为什么事务已提交还在锁表？
可能是事务未真正提交，或处于回滚过程中，需检查事务状态。
无法 KILL 阻塞线程怎么办？
若权限不足或业务不可中断，需等待事务自然结束或调整 lock_wait_timeout 超时时间。
alter table 需要多久才能不锁表？
MySQL 8.0 支持部分在线 DDL，但元数据锁阶段仍需短暂独占，无法完全无锁。
参考来源
MySQL 8.0 Reference Manual: Metadata Locking - https://dev.mysql.com/doc/refman/8.0/en/metadata-locking.html
MySQL 8.0 Reference Manual: sys Schema - https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html