MySQL Aurora 8.0执行Alter/Drop表遇锁超时，已排查仍未解决求原因

以下是几种可能导致锁等待超时但常规排查手段无法发现阻塞的原因及对应处理方式：

• 隐式未提交事务
  部分客户端或框架会开启隐式事务（比如JDBC关闭自动提交、ORM事务管理逻辑），即便查询已完成，未提交的事务仍会持有相关锁。通过INNODB_TRX视图可查询所有活跃事务：

  SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.INNODB_TRX;
  

  重点关注trx_started时间较早但trx_query为空的事务，找到对应应用连接后，在确认业务安全的前提下手动提交或回滚事务。

• 元数据锁（MDL）的隐藏持有者
  MySQL执行DDL时需要获取排他MDL锁，而一些常规操作会持有共享MDL锁，比如未提交事务中执行过目标表的查询、连接池中空闲连接残留的锁、表上正在运行的触发器/存储过程。通过performance_schema.metadata_locks可查看MDL锁详情：

  SELECT object_type, object_schema, object_name, lock_type, lock_duration, owner_thread_id FROM performance_schema.metadata_locks;
  

  找到目标表的共享锁持有者，定位到对应线程后谨慎终止（生产环境需确认无业务影响）。

• Aurora只读副本的同步阻塞
  Aurora主节点执行DDL时需同步到所有只读副本，若副本存在高延迟，或副本上有长时间运行的慢查询（比如报表类查询），会阻塞主节点的DDL执行。查看副本状态：

  SHOW SLAVE STATUS\G
  

  重点关注Seconds_Behind_Master和Slave_SQL_Running_State，若副本有慢查询，先终止该查询或等待副本追上主节点后再执行DDL。

• Aurora存储层内部锁冲突
  Aurora的分布式存储架构可能存在内部锁（如页锁、分区锁）冲突，这类情况常规InnoDB状态排查可能无法发现。可以尝试：

  • 避开业务高峰期执行DDL
  • 对大表使用ALTER TABLE ... ALGORITHM=INPLACE的在线DDL方式，减少锁持有时间
  • 检查集群的CPU、IO负载，确认是否有资源瓶颈导致锁等待超时

• 高隔离级别下的长事务
  若事务隔离级别为REPEATABLE READ或更高，未提交的长事务会持续持有快照锁，影响DDL执行。查询当前及活跃事务的隔离级别：

  SELECT @@GLOBAL.tx_isolation, @@SESSION.tx_isolation;
  SELECT trx_id, trx_isolation FROM information_schema.INNODB_TRX;
  

  优化应用逻辑，缩短事务生命周期，及时提交或回滚不必要的长事务。

内容的提问来源于stack exchange，提问作者Haroon