Waiting for table metadata lock问题处理

原文:Waiting for table metadata lock问题处理 - 膨胀的面包

在使用 mysql 的时候,我们有时会碰到 Waiting for table metadata lock 的锁等待。但是这个锁等待比较特殊,在 innodb_lock_wait 和 show engine innodb status 表里面都查不到。

该锁的影响

还是用例子来展示一下吧,更加简单直观。

ID USER HOST DB COMMAND TIME STATE INFO
1 event_scheduler localhost NULL Daemon 365869 Waiting on empty queue NULL
13006 root localhost NULL Query 35 Waiting for table metadata lock alter table test.t add column s int
13040 root localhost NULL Query 0 executing select * from information_schema.processlist where command != ‘sleep’
13044 root localhost NULL Query 4 Waiting for table metadata lock update test.t set b = 10 where a = 3
13043 root localhost NULL Query 21 Waiting for table metadata lock select * from test.t

可以看到,如果一个表产生了 Waiting for table metadata lock,那么针对该表的任何操作都会被锁住,包括 select,这对生产会产生巨大的影响。我们可以通过配置参数 lock_wait_timeout 来减少这种锁可以等待的时长。不过最重要的还是减少这种锁等待的产生。

lock_wait_timeout

This variable specifies the timeout in seconds for attempts to acquire metadata locks. The permissible values range from 1 to 31536000 (1 year). The default is 31536000.

这个参数控制的是这个 metadata 锁等待可以等待的最长时间,如果超过就会报等待超时,默认是 31536000 秒,也就是一年,可以动态修改。

那接下来将介绍两种方法来处理这种问题。

方法一:INNODB_TRX

sql:

SELECT
    t.PROCESSLIST_ID,
    t.PROCESSLIST_USER,
    t.PROCESSLIST_HOST,
    t.PROCESSLIST_DB,
    t.PROCESSLIST_STATE,
    t.PROCESSLIST_COMMAND,
    t.PROCESSLIST_TIME,
    t.PROCESSLIST_INFO,
    e.CURRENT_SCHEMA
FROM
    `performance_schema`.threads t ,
    `information_schema`.INNODB_TRX trx ,
    `performance_schema`.events_statements_history e 
WHERE
 t.thread_id = e.thread_id and 
 t.PROCESSLIST_ID = trx.trx_mysql_thread_id

如果从 INNODB_TRX 只能查到一个会话,那就算运气很好了,肯定是这个造成的。

那么如果碰到多于一个的情况呢,可以通过 PROCESSLIST_INFO 字段里面的 sql 来判断出来是哪一个。但是有些情况下,持有 metadata 锁的会话是在 sleep 状态下的。也就是说造成持有这个锁的语句已经执行过了,但是由于没有提交或者回滚,导致会话还是持有着这个锁。如果碰到这种情况,PROCESSLIST_INFO 字段就可能是空的了,那就只能通过判断会话已经执行过的语句来猜了。

当然猜也不是瞎猜,是有根据的猜。mysql 有一个 events_statements_history 表,可以通过连接这个表来查看会话执行过什么语句。如果有涉及到等待锁的表的语句就能大概猜出来是哪一个了。比如下面这个结果

PROCESSLIST_ID PROCESSLIST_USER PROCESSLIST_HOST PROCESSLIST_DB PROCESSLIST_STATE PROCESSLIST_COMMAND PROCESSLIST_TIME PROCESSLIST_INFO CURRENT_SCHEMA
12268 root localhost NULL NULL Sleep 435 NULL NULL

最后的字段显示了这个会话执行过了什么语句。12268 会话就执行过一个 select,两个 update 等等语句。这很可能说明 12268 会话持有 t 表的 metadata 锁。一般来说杀了这个会话就可以解决问题了。

但是这个 events_statements_history 有一个限制,他不会存储所有执行过的语句,而是存储最新执行过的 N 个语句。这个 N 是由 performance_schema_events_statements_history_size 控制的,该参数是只读的,只能重启 mysql 生效,默认是 10。如果执行过的语句超过了这个限制,那么很有可能是看不到对这个表进行修改的语句的,这个时候就需要猜了。

方法二:metadata_locks表

从 mysql5.7 开始,有了 performance_schema.metadata_locks 表,用于显示等待和持有 metadata 锁的会话信息。有效的简化了处理 metadata 锁等待的方法。

5.7 版本该特性不是默认开启的,需要手动启动。8.0 开始是默认开启的不需要配置。

5.7 的文档

Metadata lock instrumentation uses the wait/lock/metadata/sql/mdl instrument, which is disabled by default.

8.0 的文档

Metadata lock instrumentation uses the wait/lock/metadata/sql/mdl instrument, which is enabled by default.

在线开启方法

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

在线关闭方法

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

永久开启方法
在配置文件的 mysqld 区块里面添加

performance-schema-instrument='wait/lock/metadata/sql/mdl=ON'

sql

SELECT
    t1.OBJECT_SCHEMA,
     t1.OBJECT_NAME,
    t1.LOCK_TYPE,
    t1.LOCK_STATUS,
    t2.PROCESSLIST_ID,
    t2.PROCESSLIST_USER,
    t2.PROCESSLIST_HOST,
    t2.PROCESSLIST_DB,
    t2.PROCESSLIST_COMMAND,
    t2.PROCESSLIST_STATE,
    t2.PROCESSLIST_INFO
FROM
    `performance_schema`.metadata_locks t1,
    `performance_schema`.threads t2
WHERE
    t1.owner_thread_id = t2.thread_id
AND t1.OBJECT_SCHEMA = 'test'
AND t1.OBJECT_NAME = 't'

只有开启特性以后出现的持有或者等待 metadata 锁的会话才会被记录。

OBJECT_SCHEMA OBJECT_NAME LOCK_TYPE LOCK_STATUS PROCESSLIST_ID PROCESSLIST_USER PROCESSLIST_HOST PROCESSLIST_DB PROCESSLIST_COMMAND PROCESSLIST_STATE PROCESSLIST_INFO
test t SHARED_WRITE GRANTED 12268 root localhost test Sleep NULL NULL
test t SHARED_READ GRANTED 12268 root localhost test Sleep NULL NULL
test t SHARED_UPGRADABLE GRANTED 12378 root localhost test Query Waiting for table metadata lock alter table t add column f int
test t EXCLUSIVE PENDING 12378 root localhost test Query Waiting for table metadata lock alter table t add column f int

上面的结果中 LOCK_STATUS 字段表示连接对于 matadata 锁的持有状态,GRANTED 表示持有,PENDING 表示等待。很容易可以看出来 12268 会话持有了锁,而 12378 会话正在等待这个锁。通过 kill 12268 语句,或者让 12268 提交回滚都能解决这个问题。

总结

如果你的 mysql 还是 5.6,那么只能按照先方法一来处理。如果你的 mysql 是 5.7 版本,可以先执行
select * from performance_schema.setup_instruments WHERE NAME = 'wait/lock/metadata/sql/mdl';
来查看是不是开启了 metadata_locks 表的特性,如果开启了可以直接使用方法二来处理。那如果是 mysql8 了,那么恭喜你,可以直接使用方法二来处理,简单快捷。一般及时提交或者尽量优化 sql,缩短 sql 的执行时间,就可以减少 Waiting for table metadata lock 的出现次数了。

via:
Waiting for table metadata lock问题处理 - 简书
https://www.jianshu.com/p/a96d02d7944d

你可能感兴趣的:(mysql,mysql,数据库,数据库锁)