崩溃恢复时数据字典被锁，是因为InnoDB必须独占访问系统元数据；启动触发crash recovery后，InnoDB在dict_boot()阶段即自动加MDL_EXCLUSIVE锁，以重建、校验并重写系统表结构和内部缓存，阻塞所有DML/DDL/SELECT直至字典加载验证完成，不可绕过或降级。
崩溃恢复时数据字典被锁，是因为InnoDB必须独占访问系统元数据
MySQL启动时一旦触发 crash recovery，InnoDB 会立即对整个数据字典（data dictionary）加 MDL_EXCLUSIVE 锁，不是为了“保护DDL”，而是因为恢复过程本身要重建、校验、甚至重写系统表结构和内部缓存——此时任何并发读写都会破坏一致性。
常见现象是：启动后执行 SHOW TABLES、SELECT * FROM information_schema.tables 或任意 DML 都卡住，SHOW PROCESSLIST 显示状态为 Waiting for table metadata lock，且所有线程都阻塞在 mysql 系统库相关操作上。
- 恢复阶段需重载
mysql.ibd、ibdata1中的系统表（如mysql.columns、mysql.tables），这些表页可能损坏或版本不匹配，必须先解析 redo、回滚未提交事务、再重建字典缓存 -
MDL_EXCLUSIVE锁会阻塞所有其他会话对任何表（包括系统表和用户表）的SELECT、INSERT、ALTER等操作，直到字典加载完成并验证通过 - 这个锁不是由 SQL 语句显式申请的，而是 InnoDB 存储引擎在
dict_boot()和dict_load_tablespace()阶段自动持有的，无法绕过或降级
为什么不能跳过字典锁定？
跳过或弱化该锁会导致内存中字典缓存（TDC）与磁盘实际结构错位。比如：一个表的 CREATE TABLE 日志已写入 redo，但还没来得及持久化到数据字典表中；若此时允许并发 SELECT，InnoDB 可能按旧定义读取页，解析出错误字段偏移，直接触发断言失败或 segfault。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
典型后果包括：
- 启动后首次查询报错
Table 'mysql.user' doesn't exist（实际文件存在，但字典缓存未加载完） -
SHOW ENGINE INNODB STATUS\G中DATA DICTIONARY小节显示Loading data dictionary...卡住超过数分钟 - 错误日志出现
InnoDB: Assertion failure in file dict0boot.cc line XXX，往往就发生在字典锁释放前
哪些配置会影响字典锁持有时间？
字典锁持续时间取决于崩溃恢复的实际工作量，而非固定超时。影响因素包括：
-
innodb_log_file_size越大，redo 日志总量越多，扫描和解析耗时越长，锁持有时间越久 -
innodb_buffer_pool_size过小会导致频繁换页，拖慢页加载和 undo 应用速度 - 存在大量未清除的
TRX_UNDO_ACTIVE事务（尤其大事务未提交就崩），回滚阶段必须逐条处理 undo，期间字典锁仍被持有 - 启用
innodb_force_recovery > 0会跳过部分恢复步骤，但字典锁仍存在——只是后续操作可能因字典不完整而失败
真正容易被忽略的一点是：字典锁不是“等恢复做完才加”，而是“从第一行 redo 解析开始就锁死”
哪怕你只改了一行数据就崩溃，InnoDB 启动时也必须先锁住整个字典，再读 checkpoint、定位 LSN、打开表空间、加载系统表——这个顺序不可逆。它不像行锁可以按需加，而是恢复流程的原子前提。试图用 KILL 或 FLUSH TABLES 强行中断，只会让实例卡在不可恢复状态。
