【MySQL】metadata lock问题

1、Metadata lock

MySQL使用DML来管理对数据库对象的并发访问，并确保数据一致性。DML不只适用于表，还适用于模式和存储程序(过程、函数、触发器和计划的事件)

1.1 MDL简述

为了在并发环境下维护表元数据的数据一致性，在表上有活动事务（显式或隐式）的时候，不能够对元数据进行写入操做。所以从MySQL5.5版本开始引入了MDL锁，来保护表的元数据信息，用于解决或者保证DDL操做与DML操做之间的一致性。

元数据锁的获取不依赖于使用的引擎，不管使用的是设置autocommit=0的MyISAM引擎仍是用begin或start transaction语句显示声名的事务，链接都会获取元数据锁。一旦出现Metadata Lock Wait等待现象，后续全部对该表的访问都会阻塞在该等待上，致使链接堆积，业务受影响。

1.2 MDL解决的问题

Metadata lock 是MySQL在5.5.3版本后引入了，为的是防止5.5.3之前的一个bug的出现：

当一个会话在主库执行DML操做还没提交时，另外一个会话对同一个对象执行了DDL操做如drop table，而因为MySQL的binlog是基于事务提交的前后顺序进行记录的，所以在slave上应用时，就出现了先drop table，而后再向table中insert的状况，致使从库应用出错。

对于引入MDL，其主要解决了2个问题：

一个是事务隔离问题，好比在可重复隔离级别下，会话A在2次查询期间，会话B对表结构作了修改，两次查询结果就会不一致，没法知足可重复读的要求；

另一个是数据复制的问题，好比会话A执行了多条更新语句期间，另一个会话B作了表结构变动而且先提交，就会致使slave在重作时，先重作alter，再重作update时就会出现复制错误的现象。因此在对表进行上述操做时，若是表上有活动事务（未提交或回滚），请求写入的会话会等待在Metadata lock wait 。

2、常见MDL锁场景：

①当前有执行DML操做（DML未执行完成）时，执行DDL操做

② 当前有对表的长时间查询或使用mysqldump/mysqlpump时，执行DDL会被堵住

③ 显示或者隐式开启事务后未提交或回滚，好比查询完成后未提交或者回滚，DDL会被堵住

④ 表上有失败的查询事务，好比查询不存在的列，语句失败返回，可是事务没有提交，此时DDL仍然会被堵住

3、例子

mysql版本：5.6.29

隔离级别：READ COMMITTED

3.1 场景1

(1) 现象模拟

事务1	事务2	事务3
begin;
select * from base_code;
-	alter table base_code modify column code varchar(64) DEFAULT NULL COMMENT '编码';——执行被阻塞
-	-	select * from base_code;——执行被阻塞

(2) show processlist查看结果以下:

mysql> show processlist;
+-------+-----------------+-----------+---------+---------+----------+---------------------------------+------------------------------------------------------------------------------------+
| Id    | User            | Host      | db      | Command | Time     | State                           | Info                                                                               |
+-------+-----------------+-----------+---------+---------+----------+---------------------------------+------------------------------------------------------------------------------------+
|     1 | event_scheduler | localhost | NULL    | Daemon  | 20309270 | Waiting on empty queue          | NULL                                                                               |
| 98456 | root            | localhost | lcl_abc | Sleep   |       85 |                                 | NULL                                                                               |
| 98459 | root            | localhost | lcl_abc | Query   |       79 | Waiting for table metadata lock | alter table base_code modify column code varchar(64) DEFAULT NULL COMMENT '编码'   |
| 98461 | root            | localhost | lcl_abc | Query   |       51 | Waiting for table metadata lock | select * from base_code                                                            |
| 98462 | root            | localhost | NULL    | Query   |        0 | init                            | show processlist                                                                   |
+-------+-----------------+-----------+---------+---------+----------+---------------------------------+------------------------------------------------------------------------------------+
5 rows in set (0.00 sec)

select * from base_code; 再次查询base_code表也是 Waiting for table metadata lock状态，说明因为 metadata lock的存在，会致使后面正常的查询都会由于等待锁而阻塞。

若是先执行事务3，是能够查询的。执行完事务2，形成阻塞后，才会阻塞后续全部的操做。

(3) 查看当前事务运行状态:

mysql> select * from information_schema.innodb_trx\G
*************************** 1. row ***************************
                    trx_id: 339395
                 trx_state: RUNNING
               trx_started: 2020-04-14 16:51:43
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 0
       trx_mysql_thread_id: 98456
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 0
          trx_lock_structs: 0
     trx_lock_memory_bytes: 488
           trx_rows_locked: 0
         trx_rows_modified: 0
   trx_concurrency_tickets: 0
       trx_isolation_level: READ COMMITTED
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 10000
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
1 row in set (0.17 sec)

能够看到，事务1因为还没提交，因此这里能看到它的状态仍是running.
可是这里咱们看不到正在执行的语句，不知道究竟是什么语句致使的。

(4) 查看该事务对应的进程

mysql> select * from information_schema.processlist where id=98456;
+-------+------+-----------+---------+---------+------+-------+------+
| ID    | USER | HOST      | DB      | COMMAND | TIME | STATE | INFO |
+-------+------+-----------+---------+---------+------+-------+------+
| 98456 | root | localhost | lcl_abc | Sleep   | 1107 |       | NULL |
+-------+------+-----------+---------+---------+------+-------+------+
1 row in set (0.00 sec)

只能根据trx_mysql_thread_id看到未提交的事务的process id，看一下processlist，INFO内也没有具体内容。
此时能够经过performance_schema.events_statements_current来查看到对应的sql，包括已经执行完，但没有提交的。

mysql> SELECT b.processlist_id, c.db, a.sql_text, c.command, c.time, c.state FROM performance_schema.events_statements_current a JOIN performance_schema.threads b USING(thread_id) JOIN information_schema.processlist c ON b.processlist_id = c.id WHERE a.sql_text NOT LIKE '%performance%';
+----------------+---------+------------------------------------------------------------------------------------+---------+------+---------------------------------+
| processlist_id | db      | sql_text                                                                           | command | time | state                           |
+----------------+---------+------------------------------------------------------------------------------------+---------+------+---------------------------------+
|          98459 | lcl_abc | alter table base_code modify column code varchar(64) DEFAULT NULL COMMENT '编码'   | Query   |  636 | Waiting for table metadata lock |
|          98461 | lcl_abc | select * from base_code                                                            | Query   |  632 | Waiting for table metadata lock |
|          98456 | lcl_abc | select * from base_code                                             | Sleep   |  639 |                                 |
+----------------+---------+------------------------------------------------------------------------------------+---------+------+---------------------------------+
3 rows in set (0.05 sec)

(5) 提交或关闭形成DML锁的进程

提交或者kill 98456后，能够看到事务二、事务3立马执行完了

mysql> alter table base_code modify column code varchar(64) DEFAULT NULL COMMENT '编码';
Query OK, 7 rows affected (21 min 58.00 sec)
Records: 7  Duplicates: 0  Warnings: 0

3.2 场景2：

事务1,开启事务，执行语句报错，其余语句获取到的锁在这个事务提交或回滚以前，仍然不会释放掉

(1) 现象模拟

事务1	事务2	事务3
begin;
update base_code set num2=1 where id=1;——ERROR 1054 (42S22): Unknown column 'num2' in 'field list'
-	alter table base_code modify column code varchar(64) DEFAULT NULL COMMENT '编码';——执行被阻塞
-	-	select * from base_code;——执行被阻塞

因为num2字段不存在，事务1执行报错，致使update执行失败，可是没有提交该事务，此时依然会形成alter语句阻塞，之后后续的select阻塞。

(2)show processlist查看结果以下：

mysql> show processlist;
+-------+-----------------+-----------+---------+---------+----------+---------------------------------+------------------------------------------------------------------------------------+
| Id    | User            | Host      | db      | Command | Time     | State                           | Info                                                                               |
+-------+-----------------+-----------+---------+---------+----------+---------------------------------+------------------------------------------------------------------------------------+
|     1 | event_scheduler | localhost | NULL    | Daemon  | 20314642 | Waiting on empty queue          | NULL                                                                               |
| 98456 | root            | localhost | lcl_abc | Sleep   |     1030 |                                 | NULL                                                                               |
| 98459 | root            | localhost | lcl_abc | Query   |      983 | Waiting for table metadata lock | alter table base_code modify column code varchar(64) DEFAULT NULL COMMENT '编码'   |
| 98461 | root            | localhost | lcl_abc | Query   |        3 | Waiting for table metadata lock | select * from base_code                                                            |
| 98462 | root            | localhost | NULL    | Query   |        0 | init                            | show processlist                                                                   |
+-------+-----------------+-----------+---------+---------+----------+---------------------------------+------------------------------------------------------------------------------------+
5 rows in set (0.00 sec)

(3) 查看当前事务运行状态:

在information_schema.innodb_trx中也没有任何进行中的事务.需查询表performance_schema.events_statements_current，该表能够看到对应的sql，包括已经执行完，但没有提交的

缺陷：一个事务可能有一组sql组成，这个方法只能看到这个事务最后执行的是什么SQL，没法看到所有。(假如事务1，执行完update后又执行了一个select，则events_statements_current表中只能看到最后执行的select语句)

mysql> SELECT b.processlist_id, c.db, a.sql_text, c.command, c.time, c.state FROM performance_schema.events_statements_current a JOIN performance_schema.threads b USING(thread_id) JOIN information_schema.processlist c ON b.processlist_id = c.id WHERE a.sql_text NOT LIKE '%performance%';
+----------------+---------+------------------------------------------------------------------------------------+---------+------+---------------------------------+
| processlist_id | db      | sql_text                                                                           | command | time | state                           |
+----------------+---------+------------------------------------------------------------------------------------+---------+------+---------------------------------+
|          98459 | lcl_abc | alter table base_code modify column code varchar(64) DEFAULT NULL COMMENT '编码'   | Query   |  636 | Waiting for table metadata lock |
|          98461 | lcl_abc | select * from base_code                                                            | Query   |  632 | Waiting for table metadata lock |
|          98463 | lcl_abc | update base_code set num2=1 where id=1                                             | Sleep   |  639 |                                 |
+----------------+---------+------------------------------------------------------------------------------------+---------+------+---------------------------------+
3 rows in set (0.05 sec)

4、参数

能够经过 lock_wait_timeout 变量来指定超时时间，默认是31536000秒（一年），因此锁住的查询永远不会终止。

5、总结

• 为了事务的串行话，和数据一致性， Mysql会对打开事务进行DML的表加上table metadata lock,在事务提交前，其余的DDL操做会阻塞
• 对于主要是查询数据的项目来讲，默认不开启事务便可，若是确实须要，程序上手动开启事务
• 须要使用到事务时，也要尽可能缩小事务的运行时间，一个事务中不要包含太多的语句
• 程序上对任何错误异常情况必定要捕捉后，回滚事务，不然事务脱离程序，只能等事务本身超时，手动关闭事务或者重启服务释放锁了

6、查找未提交事务的sql的方法

(1) 表performance_schema.events_statements_current

缺陷：一个事务可能有一组sql组成，这个方法只能看到这个事务最后执行的是什么SQL，没法看到所有。(假如事务1，执行完update后又执行了一个select，则events_statements_current表中只能看到最后执行的select语句)

(2) general_log

即便事务没有提交，同样会写到general_log.
缺陷：通常状况下general_log不大可能打开.

(3) commit后，查看binlog

假如后面应用层最终commit了，那么会在binlog里记录，能够根据当时的tread_id去binlog查看缺陷：不会记录select、执行失败的语句。