MySQL 8.0 中无专用备份锁视图，仅能通过 performance_schema.metadata_locks 表查询，筛选条件为 OBJECT_TYPE = 'BACKUP' AND LOCK_STATUS = 'GRANTED'；该表需启用 performance_schema_metadata_locks_enabled，且 8.0.22+ 版本才完整支持。
MySQL 8.0 中哪些系统视图能查备份锁状态？
MySQL 8.0 引入了 performance_schema 对备份锁（BACKUP LOCK）的跟踪支持，但**没有专用的“备份锁视图”**。真正可用的是 performance_schema.metadata_locks 表，它会把备份锁作为一类元数据锁记录下来，类型为 BACKUP。
注意：该表默认可能关闭，需确认配置：
-
performance_schema必须启用（performance_schema=ON） -
performance_schema_metadata_locks_enabled必须为ON（5.7.3 之后默认开启，但某些旧升级实例可能被手动关掉）
如何准确筛选出备份锁记录？
直接查 performance_schema.metadata_locks 时，备份锁的 OBJECT_TYPE 是 BACKUP，且 LOCK_TYPE 通常为 INTENTION_EXCLUSIVE 或 SHARED_HIGH_PRIO（取决于 LOCK INSTANCE FOR BACKUP 是否带 READ ONLY）。关键筛选条件是：
OBJECT_TYPE = 'BACKUP'-
LOCK_STATUS = 'GRANTED'（只看已生效的锁，避免干扰等待中的） - 可选加
OWNER_THREAD_ID关联performance_schema.threads查具体会话
示例查询：
SELECT THREAD_ID, OBJECT_TYPE, LOCK_TYPE, LOCK_DURATION, LOCK_STATUS, OWNER_THREAD_ID FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'BACKUP' AND LOCK_STATUS = 'GRANTED';
为什么查不到备份锁？常见原因有哪些？
即使执行了 LOCK INSTANCE FOR BACKUP，也可能查不到记录，主要因为：
-
performance_schema.metadata_locks表不记录“全局实例级锁”的全部上下文——它只在锁实际被申请并进入 MDL 子系统时才插入行；而LOCK INSTANCE FOR BACKUP的部分逻辑绕过标准 MDL 流程（尤其在只读模式下） -
LOCK INSTANCE FOR BACKUP成功后，若未紧接着做 DDL/DML（比如没触发任何表级锁请求），metadata_locks可能为空 - 用户权限不足：
SELECT权限需授予performance_schema.*，不是所有账号默认拥有 - MySQL 8.0.22+ 才完整支持将
BACKUP类型写入该表；低于此版本（如 8.0.16）可能只显示为GLOBAL类型或完全不显示
有没有更直接的替代方式验证备份锁生效？
依赖系统视图有局限，建议配合以下手段交叉验证：
- 执行
SHOW PROCESSLIST，检查是否有线程状态为Locked for backup - 尝试在另一会话执行
DROP DATABASE或ALTER INSTANCE ROTATE INNODB MASTER KEY—— 若被阻塞，说明备份锁正在起作用 - 查看错误日志：
LOCK INSTANCE FOR BACKUP成功时通常无日志，但失败时会有明确提示，如ER_BACKUP_LOCK_ACTIVE - 注意：
information_schema.INNODB_TRX和INNODB_LOCKS不包含备份锁信息，不要在这两个表里浪费时间查找
备份锁本质是轻量级实例级协调机制，它不像事务锁那样全程落表；想靠单个视图“一览无余”不太现实，得结合状态、行为和日志综合判断。
