Skip to content

metadata_locks

Jump to bottom
xiaoboluo768 edited this page Jun 8, 2020 · 2 revisions
  • Performance Schema通过metadata_locks表记录元数据锁信息：
    • 已授予的锁（显示哪些会话拥有当前元数据锁）
    • 已请求但未授予的锁（显示哪些会话正在等待哪些元数据锁）
    • 已被死锁检测器检测到并被杀死的锁，或者锁请求超时正在等待锁请求会话被丢弃
  • 这些信息使您能够了解会话之间的元数据锁依赖关系。不仅可以看到会话正在等待哪个锁，还可以看到当前持有该锁的会话ID
  • metadata_locks表是只读的，无法更新。默认保留行数会自动调整，如果要配置该表大小，可以在server启动之前设置系统变量performance_schema_max_metadata_locks的值
  • 元数据锁instruments使用wait/lock/metadata/sql/mdl，默认未开启
  • 要在server启动时启动元数据锁instruments，可以在my.cnf文件中使用performance-schema-instrument='wait/lock/metadata/sql/mdl=ON'，如果要关闭，则使用performance-schema-instrument='wait/lock/metadata/sql/mdl=OFF'，或者在运行时使用如下SQL语句进行开关
UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl';

UPDATE setup_instruments SET ENABLED = 'NO', TIMED = 'NO' WHERE NAME = 'wait/lock/metadata/sql/mdl';

  • performance_schema维护metadata_locks表中的内容如下(使用LOCK_STATUS列来表示每个锁的状态）：

    • 当请求立即获取元数据锁时，将插入状态为GRANTED的锁信息行
    • 当请求元数据锁不能立即获得时，将插入状态为PENDING的锁信息行
    • 当之前请求不能立即获得的锁在这之后被授予时，其锁信息行状态更新为GRANTED
    • 释放元数据锁时，对应的锁信息行被删除
    • 当一个pending状态的锁被死锁检测器检测并选定为用于打破死锁时，这个锁会被撤销，并返回错误信息（ER_LOCK_DEADLOCK）给请求锁的会话，锁状态从PENDING更新为VICTIM
    • 当待处理的锁请求超时，会返回错误信息（ER_LOCK_WAIT_TIMEOUT）给请求锁的会话，锁状态从PENDING更新为TIMEOUT
    • 当已授予的锁或挂起的锁请求被杀死时，其锁状态从GRANTED或PENDING更新为KILLED
    • VICTIM，TIMEOUT和KILLED状态值停留时间很简短，当一个锁处于这个状态时，那么表示该锁行信息即将被删除（手动执行SQL可能因为时间原因查看不到，可以使用程序抓取）
    • PRE_ACQUIRE_NOTIFY和POST_RELEASE_NOTIFY状态值停留事件都很简短，当一个锁处于这个状态时，那么表示元数据锁子系统正在通知相关的存储引擎该锁正在执行分配或释。这些状态值在5.7.11版本中新增

  • metadata_locks表字段含义如下：

    • OBJECT_TYPE：元数据锁子系统中使用的锁类型（类似setup_objects表中的OBJECT_TYPE列值）：有效值为：GLOBAL、SCHEMA、TABLE、FUNCTION、PROCEDURE、TRIGGER（当前未使用）、EVENT、COMMIT、USER LEVEL LOCK、TABLESPACE、LOCKING SERVICE，USER LEVEL LOCK值表示该锁是使用GET_LOCK（）函数获取的锁。LOCKING SERVICE值表示使用锁服务获取的锁（详见链接：https://dev.mysql.com/doc/refman/5.7/en/locking-service.html）
    • OBJECT_SCHEMA：该锁来自于哪个库级别的对象
    • OBJECT_NAME：instruments对象的名称，表级别对象
    • OBJECT_INSTANCE_BEGIN：instruments对象的内存地址
    • LOCK_TYPE：元数据锁子系统中的锁类型。有效值为：INTENTION_EXCLUSIVE、SHARED、SHARED_HIGH_PRIO、SHARED_READ、SHARED_WRITE、SHARED_UPGRADABLE、SHARED_NO_WRITE、SHARED_NO_READ_WRITE、EXCLUSIVE
    • LOCK_DURATION：来自元数据锁子系统中的锁定时间。有效值为：STATEMENT、TRANSACTION、EXPLICIT，STATEMENT和TRANSACTION值分别表示在语句或事务结束时会释放的锁。 EXPLICIT值表示可以在语句或事务结束时被会保留，需要显式释放的锁，例如：使用FLUSH TABLES WITH READ LOCK获取的全局锁
    • LOCK_STATUS：元数据锁子系统的锁状态。有效值为：PENDING、GRANTED、VICTIM、TIMEOUT、KILLED、PRE_ACQUIRE_NOTIFY、POST_RELEASE_NOTIFY。performance_schema根据不同的阶段更改锁状态为这些值
    • SOURCE：源文件的名称，其中包含生成事件信息的检测代码行号
    • OWNER_THREAD_ID：请求元数据锁的线程ID
    • OWNER_EVENT_ID：请求元数据锁的事件ID

  • metadata_locks表不允许使用TRUNCATE TABLE语句

  • 表记录内容示例

admin@localhost : performance_schema 04:55:42> select * from metadata_locks\G;
*************************** 1. row ***************************
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: xiaoboluo
          OBJECT_NAME: test
OBJECT_INSTANCE_BEGIN: 140568048055488
            LOCK_TYPE: SHARED_READ
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: GRANTED
              SOURCE: sql_parse.cc:6031
      OWNER_THREAD_ID: 46
      OWNER_EVENT_ID: 49
*************************** 2. row ***************************
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: performance_schema
          OBJECT_NAME: metadata_locks
OBJECT_INSTANCE_BEGIN: 140568105637712
            LOCK_TYPE: SHARED_READ
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: GRANTED
              SOURCE: sql_parse.cc:6031
      OWNER_THREAD_ID: 47
      OWNER_EVENT_ID: 9
2 rows in set (0.00 sec)
  • 表结构定义
CREATE TABLE `metadata_locks` (
  `OBJECT_TYPE` varchar(64) NOT NULL,
  `OBJECT_SCHEMA` varchar(64) DEFAULT NULL,
  `OBJECT_NAME` varchar(64) DEFAULT NULL,
  `OBJECT_INSTANCE_BEGIN` bigint(20) unsigned NOT NULL,
  `LOCK_TYPE` varchar(32) NOT NULL,
  `LOCK_DURATION` varchar(32) NOT NULL,
  `LOCK_STATUS` varchar(32) NOT NULL,
  `SOURCE` varchar(64) DEFAULT NULL,
  `OWNER_THREAD_ID` bigint(20) unsigned DEFAULT NULL,
  `OWNER_EVENT_ID` bigint(20) unsigned DEFAULT NULL
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

上一篇： replication_group_members表 | 下一篇： table_handles表

  • 验证、测试、整理：罗小波
  • QQ：309969177
  • 提示：本系列文章的主体结构遵循Oracle MySQL 官方 5.7 手册中，关于information_schema、mysql schema、performance_schema、sys schema的章节结构体系，并额外添加了一些验证、测试数据。鉴于本人精力和能力有限，难免出现一些纰漏，欢迎大家踊跃指正！
Clone this wiki locally