先确认阻塞源：执行SHOW FULL PROCESSLIST定位State为Waiting for table metadata lock的线程及对应表，再查INNODB_TRX找未提交长事务；云环境无法直接KILL，需联系业务提交/回滚或提工单处理。
show processlist 里看到 Waiting for table metadata lock 怎么办
这说明已经有会话在持有目标表的 MDL 锁，而你的 DDL（比如 ALTER TABLE）或另一条 DML 正在等待写锁。云数据库如 RDS 默认不开放 KILL 权限，不能直接杀连接，得靠平台工具或权限配置。
先执行：show full processlist;
重点看 State 列是否大量出现 Waiting for table metadata lock，再对照 Info 列确认阻塞发生在哪张表、哪个 SQL 上。
- 如果阻塞源是长事务（比如未提交的
SELECT ... FOR UPDATE或显式BEGIN后没COMMIT），需联系业务方尽快提交或回滚 - 如果是运维脚本或应用连接池未正确释放连接（例如 Python 中漏掉
cursor.close()和conn.close()），要修复代码并重启应用 - RDS 控制台通常提供「会话管理」或「慢 SQL 分析」功能，可按
DBName、Host、Command过滤活跃会话，定位源头
为什么 ALTER TABLE 在 RDS 上特别容易卡住
云数据库普遍启用 innodb_lock_wait_timeout（默认 50 秒），但 MDL 锁等待不走这个超时路径——它独立于 InnoDB 行锁机制，属于 Server 层元数据保护逻辑。只要持有锁的会话不退出、不提交、不断连，DDL 就一直挂起。
- MySQL 5.6+ 的事务级 MDL 持有逻辑：一个事务内只要访问过某张表（哪怕只是
SELECT），就会持有一个MDL_SHARED_READ锁，直到事务结束 - RDS 实例默认开启
autocommit=1，但应用层若显式执行BEGIN，后续又没COMMIT，就极易制造隐形长事务 - 某些云厂商（如华为云 DAS）提供「MDL 锁分析」视图，能直接展示锁等待链，比手查
information_schema.PROCESSLIST更直观
在 RDS 上安全执行 DDL 的实操要点
不能依赖“等它自己好”，必须前置控制 + 实时干预。云环境对 KILL 权限限制严格，所以预防比解救更重要。
- 避开备份窗口：RDS 全量备份期间禁止 DDL，否则会因
MDL冲突导致备份失败（错误提示常为Error 1105） - 加
LOCK WAIT TIMEOUT：MySQL 8.0.12+ 支持ALTER TABLE ... LOCK=NONE, ALGORITHM=INSTANT，但前提是字段类型变更兼容；否则至少用ALGORITHM=INPLACE并配WAIT 10（单位秒），超时自动失败，避免无限等待 - 用
pt-online-schema-change或gh-ost：这类工具通过影子表+触发器或 binlog 回放绕过原表MDL写锁，但 RDS 需确认是否允许创建触发器、是否开放BINLOG_FORMAT=ROW权限 - 提前检查长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60;，超过 60 秒的事务建议预警
RDS 管理控制台能做什么、不能做什么
不同云厂商能力差异大，但共性是：能看不能杀、能查不能改、能告警不能自动熔断。别指望点几下就自动解 MDL 锁。
- 华为云 DAS、阿里云 DMS、腾讯云 DBbrain 都支持基于
MDL等待状态的可视化诊断，但「强制 KILL」按钮往往灰掉或需工单申请 - 部分 RDS 版本（如 MySQL 8.0 高可用版）支持
performance_schema.metadata_locks表，可查锁类型（SHARED_READ/EXCLUSIVE）、持有者线程 ID、阻塞关系，但需开启相关 instrumentation - 真正关键的权限（如
SUPER或CONNECTION_ADMIN）通常被云平台屏蔽，这意味着你无法用KILL CONNECTION直接终结问题会话——得靠业务侧配合或提工单
MDL 锁本身不可见、不可配置超时、不可降级，它藏在 Server 层最底层。云环境放大了它的“静默破坏力”：没有 root 权限，就只能靠监控+协作+工具链来兜底。任何 DDL 变更前，务必确认无活跃事务、无连接泄漏、无备份任务在跑。
