MySQL锁信息重启后必然消失，因其由InnoDB和Server层在内存中动态维护、不持久化；锁是临时并发控制机制，依赖运行时上下文，重启后事务ID等全部重置，旧锁无法映射。

MySQL 的锁信息重启后必然消失——这不是 bug，而是设计使然。锁（包括行锁、表锁、元数据锁）全部由 InnoDB 和 Server 层 在内存中动态维护，不落盘、不持久化。服务一停，内存清空，锁自然归零。

锁信息为什么不能跨重启保留

锁的本质是并发控制的临时协调机制，不是数据状态。它只在事务活跃期间存在，用于阻塞冲突操作；一旦连接断开或事务提交/回滚，锁立即释放。MySQL 没有、也不该把锁写入磁盘：

• INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCKS（5.7）、performance_schema.data_locks（8.0+）等视图全靠内存结构实时构建，重启后这些结构重建，历史锁记录彻底丢失
• 如果锁被持久化，事务恢复逻辑将变得不可控：比如一个已提交事务的锁还“挂着”，后续连接可能被误阻塞
• 锁依赖事务 ID、线程 ID、页号、索引记录等运行时上下文，这些值重启后全部重置，旧锁无法映射到新实例

常见误判场景：以为“锁还在”，其实是新锁或残留事务

重启后观察到类似锁等待的现象，往往不是旧锁复活，而是以下情况：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 应用未正确关闭连接，重启后快速重连并立刻执行相同 SQL，**新事务又抢到了同一行/表，触发新一轮锁等待**
• 配置了 innodb_fast_shutdown = 1（默认），导致部分脏页和事务状态未完全刷盘，崩溃恢复时可能回滚不完整，**看起来像“锁没释放”，实则是事务异常终止后资源未清理干净**
• 使用了 LOCK TABLES 显式加表锁，但会话未执行 UNLOCK TABLES 就断连 —— 这类锁在连接断开时由 MySQL 自动释放，**重启后根本不存在残留**

想查“重启前谁持有了什么锁”？唯一可行路径是日志回溯

锁本身不留痕，但它的行为会留下痕迹。真要定位重启前的锁争用，只能依赖外部可观测性：

• 开启 slow_query_log 并设置 long_query_time = 0，配合 log_output = 'TABLE'，锁等待超时的语句会记入 mysql.slow_log
• 启用 performance_schema 的锁监控（如 data_lock_waits），但注意：这些表内容**同样不跨重启存活**，需搭配定时采集脚本（如每分钟 SELECT * FROM performance_schema.data_lock_waits 写入归档表）
• 关键业务节点主动记录锁上下文：在执行 SELECT ... FOR UPDATE 前，把 CONNECTION_ID()、NOW()、SQL 片段写入业务审计表
• 错误日志（error_log）里若出现 Lock wait timeout exceeded，说明当时已有严重锁等待，这是最直接的间接证据

锁信息重启即失，是内存型锁管理器的固有边界。指望它留存，就像指望 TCP 连接状态在网卡断电后还能恢复——系统设计上就放弃了这个方向。真正要防的，不是“锁丢了”，而是“为什么总在重启前卡死”，那背后通常是长事务、缺失索引或应用层连接复用失控。