MySQL metadata lock

什么是元数据

描述数据库中的数据的数据都是元数据,如库名、表明、列名、版本名,和show语句展示的大多数内容都是元数据,以及在information_shema中记录数据库对象的表中的内容也是元数据

为什么MySQL要设置元数据锁

为了保证可以并发访问数据库对象及保证数据的一致性,所以应用metadata lock,如session1正在扫描t表数据,此会话持有t表的元数据锁,这时session2话尝试要drop t表,在尝试获取t表元数据锁的时候被阻塞,假如没有MDL的设计,那么在session1执行完之前session2将表drop掉,那么就会出现优化器在扫描到表一半时候突然抛出表不存在的异常

MDL的工作原理

在同一事务中操作事务表t和非事务表nt,如果此事务不结束,则另一会话对表t和nt的ddl操作都无法进行

如果事务中的语句通过语法校验但在执行的时候抛出异常,但是此事务不结束,对其涉及到的表的ddl操作也被阻塞,测试见例二

测试MDL

例一

# session1
14:14:13[test](;)> begin;
Query OK, 0 rows affected (0.00 sec)

14:14:18[test](;)> select * from t1 limit 1;
+----+------+------+------+
| id | col1 | col2 | col3 |
+----+------+------+------+
|  2 |    3 |    5 | NULL |
+----+------+------+------+
1 row in set (0.00 sec)

#session2
14:14:48[test](;)> alter table t1 add col4 int;

#session3
| 4834501 | root        | localhost | test | Query   |      14 | Waiting for table metadata lock                        | alter table t1 add col4 int |

例二

session1
14:28:36[test](;)> begin;
Query OK, 0 rows affected (0.00 sec)

14:28:40[test](;)> insert into t1(id) values(2);
ERROR 1062 (23000): Duplicate entry ‘2‘ for key ‘PRIMARY‘

session2
14:28:40[test](;)> alter table t1 drop col4;

session3
| 4834501 | root        | localhost | test | Query   |      12 | Waiting for table metadata lock                        | alter table t1 drop col4 |

MDL的等待超时时长默认值为一年

14:17:32[(none)](;)> select @@lock_wait_timeout;
+---------------------+
| @@lock_wait_timeout |
+---------------------+
|            31536000 |
+---------------------+
1 row in set (0.00 sec)

建议

在操作频繁的时候尽量避免大表的DDL操作;MDL超时时长可以根据业务场景设置;有必要做MDL的监控报警

官方文档:https://dev.mysql.com/doc/refman/5.6/en/metadata-locking.html

时间: 2024-10-13 21:13:02

MySQL metadata lock的相关文章

mysql metadata lock(二)

上一篇<mysql metadata lock(一)>介绍了为什么引入MDL,MDL作用以及MDL锁导致阻塞的几种典型场景,文章的最后还留下了一个小小的疑问.本文将更详细的介绍MDL,主要侧重介绍MDL的原理和实现.一般而言,商业数据库系统实现锁,一般将锁划分为读锁(共享锁)和写锁(排它锁),为了进一步提高并发性,还会加入意向共享锁和意向排它锁.但是偏偏mysql的MDL搞地比较复杂,但目的也是为了提高并发度.MDL包含有9种类型,详细参考表1.主要其实也是两大类,只是对共享锁做了进一步细分.

mysql metadata lock锁

很多情况下,很多问题从理论上或者管理上而言都是可以避免或者说很好解决的,但是一旦涉及到现实由于管理或者协调或者规范执行的不够到位,就会出现各种各样本不该出现的问题,这些问题的通常在生产环境并不会出现,但是现实是无论在任何环节出现,都得去找到解决方法,很多时候原因是一部分,预防措施也是一部分,但解决方法也是必须的,因为不可能跟所有的开发人员说你按照我说的做就没有问题了,因为总会有人疏忽了或者忽视了. 前两天,测试环境升级脚本,跑到一半就报锁超时了,好几次后测试让协助而解决下.看了下,是个trunc

MySQL metadata lock阻塞问题

2017年4月1日星期六 在某个业务的主库加完2个字段后,业务方反馈在30分钟后从库也一直无法查看到这个新字段. 在slave上执行show slave status\G 如下图 show porcesslist; 如下图: 上图2张图,可以看到延迟较大,从库上的alter操作一直在等待metadata lock,处于阻塞状态. 解决方法: 使用SELECT * FROM information_schema.innodb_trx\G找到那个事务未提交导致的问题: kill2359; 杀掉这个线

RDS MySQL 表上 Metadata lock 的产生和处理

1. Metadata lock wait 出现的场景 2. Metadata lock wait 的含义 3. 导致 Metadata lock wait 等待的活动事务 4. 解决方案 5. 如何避免出现长时间 Metadata lock wait 导致表上相关查询阻塞,影响业务 1. Metadata lock wait 出现的场景 创建.删除索引 修改表结构 表维护操作(optimize table.repair table 等) 删除表 获取表上表级写锁 (lock table tab

MySQL出现Waiting for table metadata lock的原因以及解决方法

转自:http://ctripmysqldba.iteye.com/blog/1938150 (有修改) MySQL在进行alter table等DDL操作时,有时会出现Waiting for table metadata lock的等待场景.而且,一旦alter table TableA的操作停滞在Waiting for table metadata lock的状态,后续对TableA的任何操作(包括读)都无法进行,因为他们也会在Opening tables的阶段进入到Waiting for

Mysql事物与Metadata lock 问题

环境说明: MySQL 5.6.16 OS:Linux RedHat 6.2 64bit 1.问题描述 目前新上一个使用MySQL数据库项目,在数据库中,每隔5分钟做truncate某个表操作,经常出现metadata lock锁等待,导致后面的对这个表的所有操作(包括读)全部metadata lock等待.严重影响了数据库运行. 且metadata lock锁等待不同于普通的行级锁,等待超时时间默认为365天,而普通的行级锁超时是120s mysql> show variables like

关于mysql的metadata lock

昨天晚上上线,却发现一个ddl语句长时间没有生效 查processlist, 发现包括ddl语句在内的众多查询提示 “Waiting for table metadata lock” 唯一没有该提示的查询为一个全表查询,并且Time项数值最大. kill掉这个查询的线程,后面的ddl语句正常进行了 之前一直听说metadata lock,就是元数据锁,也叫字典锁或者表结构锁.但是没有遇到过. 后来又试了一下——只要在session1里有未完成的增删查改事务,如果在另一个session2中出现加表

mysql出现Waiting for table metadata lock的原因及解决方案

最近经常遇到mysql数据库死锁,郁闷死,show processlist; 时 Waiting for table metadata lock 能一直锁很久 下面有官网的一段话,可以理解下http://dev.mysql.com/doc/refman/5.5/en/metadata-locking.html 8.10.4. Metadata LockingMySQL 5.5.3 and up uses metadata locking to manage access to objects (

【MySQL经典案例分析】 Waiting for table metadata lock

本文由云+社区发表 一. 问题是这样来的 ? 2018年某个周末,接到连续数据库的告警,告警信息如下: 二. 苦逼的探索过程 1.总体的思路 看到too many connection的报错信息,基本上可以把问题定位在: (1)机器负载飙升,导致SQL执行效率下降,导致连接推积 (2)业务访问量突增(或者有SQL注入现象),导致连接数打满 (3)出现"死锁"或者锁竞争严重,导致大量SQL堆积 2.排查过程 (1)机器的各项性能指标都显示正常, 没有出现高负载现象,暂时先排除了这种原因