MariaDB 10.8含外键的表执行alter/drop等操作无法完成无报错

优先排查元数据锁（MDL）阻塞 #

这是该场景下最高发的诱因，和外键约束逻辑、foreign_key_checks配置无关，且InnoDB监控不会输出相关错误，完全匹配描述的现象：

• 新开一个独立的MariaDB连接（不要用现有已经执行过查询的窗口），执行SHOW FULL PROCESSLIST;
• 查看结果中State字段值为Waiting for table metadata lock的记录，这些就是被阻塞的变更会话；再找所有长时间处于sleep状态、且Time字段值很大的会话，这些就是持有锁未释放的阻塞源
• 最常见的阻塞源场景：
  • 之前打开的查询窗口手动关闭了自动提交，执行过父子表的查询/修改后没有提交/回滚事务，一直持有元数据锁
  • VS Code等第三方数据库插件默认关闭自动提交，执行表预览等操作后未自动释放锁
  • 后台运行的备份、定时任务中途卡住未释放连接
• 确认阻塞会话无正在运行的重要任务后，执行KILL <阻塞会话的ID>;释放锁，即可正常执行变更语句。

注意：foreign_key_checks=OFF只会跳过外键逻辑校验，不会绕过MDL锁校验，只要有未提交的会话持有相关表的元数据锁，变更操作就会无限等待，不会返回报错。

排查InnoDB外键元数据一致性 #

MariaDB 10.8在Windows平台存在小概率的元数据不匹配bug：存储引擎层记录的外键信息和表定义文件记录不一致时，涉及外键的表变更会卡在引擎层无报错：

• 分别执行以下两条语句，对比外键定义：

  SHOW CREATE TABLE <你的子表名>; -- 记录输出中CONSTRAINT段落的外键名称、关联字段、关联父表
  SELECT * FROM information_schema.INNODB_FOREIGN WHERE FOR_NAME LIKE '%<你的子表名>%'; -- 查看引擎层存储的外键记录
  

• 如果两边的外键名称、关联字段、父表信息不一致，先通过mysqldump导出两张表的全量数据做备份，再执行以下操作重建外键：

  SET foreign_key_checks = 0;
  ALTER TABLE <子表名> DROP FOREIGN KEY <记录下的外键名>;
  ALTER TABLE <子表名> ADD CONSTRAINT <自定义外键名> FOREIGN KEY (participant_id) REFERENCES <父表名>(id);
  SET foreign_key_checks = 1;
  

排查Windows系统层面的文件锁 #

Windows平台的文件强制锁机制会导致InnoDB无法获取表文件写权限时无限等待，不会抛出明确错误：

• 关闭所有数据库客户端（包括官方命令行客户端、VS Code数据库插件、可视化管理工具），打开任务管理器结束残留的mariadb.exe、mysqldump.exe用户进程（不要结束MariaDB服务主进程）
• 检查MariaDB数据目录（默认路径为C:\Program Files\MariaDB 10.8\data）下对应两张表的.ibd、.frm文件，是否被OneDrive等同步盘、Windows Defender等杀毒软件占用扫描
• 将MariaDB数据目录加入杀毒软件、同步盘的排除列表，避免文件被锁定。

表损坏场景处理 #

如果以上排查都未解决问题，再验证表是否损坏：

• 先正常停止MariaDB服务，拷贝整个data目录做全量冷备份，避免数据丢失
• 重启服务后先对无外键的正常表执行CHECK TABLE <正常表名>;确认服务状态正常，再对父子表分别执行CHECK TABLE <表名>;，查看返回的Msg_text字段是否有损坏提示
• 如果确认表损坏，优先用之前导出的逻辑备份恢复数据，不要直接在Windows环境下执行REPAIR TABLE——InnoDB表的修复操作遇到文件锁时大概率会直接卡住。

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