前言：元数据锁不是锁定数据，而是锁定描述数据的元数据信息。就像很多装修工人（工作线程）在室内（对象上）装修（操作），不能有其他工人（线程）把屋子拆了（表删除了）。
MySQL 为了数据一致性使用元数据锁来管理并发访问数据库中的对象。元数据锁不仅仅作用于表上，同时对存储程序（schemas，procedure，function，triggers，events)以及表空间都适用。
译者废话：也就是说，为防止一个线程在插入一条记录，另一个线程删了表。所以在第一个线程在写入时，还要有元数据锁。
性能数据库（Performance Schema）中的 metadata_lock 表记录了关于元数据锁的信息。其中可以看到哪个会话持有锁、因为等待锁被堵塞等等。关于这个表的详细信息请看。
https://dev.mysql.com/doc/refman/5.7/en/metadata-locks-table.html
元数据锁定会涉及一些开销，随着查询量的增加而增加。 元数据争用会增加，多个查询尝试访问相同对象。
元数据锁定不是table definition cache的替代品，他的互斥锁（mutexes）和锁（locks）与LOCK_open互斥锁不同。 以下讨论提供了有关元数据锁定如何工作的一些信息。
获得元数据锁
释放元数据锁
获得元数据锁
笔者废话：也就说读锁要让着写锁。这在数据库内部随处可见。写不能被饿死在文件系统也可体现呢。
语句逐个获取元数据锁，而不是同时获取，并在此过程中执行死锁检测。
DML语句获得锁的顺序和语句中提及到的表顺序一致。
DDL语句，LOCK TABLES和其他类似语句尝试通过按名称顺序获取显式命名表上的锁来减少并发DDL语句之间可能出现的死锁数。 对于隐式使用的表，可能以不同的顺序获取锁，比如外键关系的表也会被锁。笔者废话：一定要注意其中的名称顺序，实际上就是名称字典序。并非SQL语句中提及到的顺序。
比如说 RENAME TABLE 是一个DDL语句，它会根据顺序来获取锁。a c d
RENAME TABLE tbla TO tbld, tblc TO tbla;
如下获得锁顺序: a b c
RENAME TABLE tbla TO tblb, tblc TO tbla;
笔者废话：这就是废话吧）
当多个事务同时执行时，元数据锁获取顺序可以在操作结果上产生差异，如下例所示。
从两个具有相同结构的表x和x_new开始。 三个客户端发出涉及这些表的语句：
session1 LOCK TABLE x WRITE, x_new WRITE;
这个语句按x 、x_new 请求并获得锁。
session2 INSERT INTO x VALUES(1);
这个会话会被堵塞，因为它在等待x 的 写锁。
session3 RENAME TABLE x TO x_old, x_new TO x;
这个语句请求获得排他锁（exclusive lock），顺序是 x, x_new, x_old 。但是因为要获取x 写锁而被堵塞
session1 UNLOCK TABLES;
笔者注：这里的session3是要对metadata进行更改，所以需要的是一个排他锁，而session2对x表进行插入，并不涉及更改x的metadata，所以只是一个读锁，读锁是可以被其他读锁共享，也就是说不会影响其他插入。至于文档为什么写时write lock。不得而知。由于上述session2 ，session3 的两个操作都是瞬时完成，不好判断谁先谁后，读者可以根据binlog生成的顺序来验证。其实在官方的这个案例中，自带了有趣的验证，因为由于是先改名后插入，所以新插入的数据，实际上是在改名后的表中。）
mysql> SELECT * FROM x;
+------+ | i |
+------+ | 1 | +------+
mysql> SELECT * FROM x_old;
Empty set (0.01 sec)
以上证明了写锁高于读锁的请求
=================
现在来看以下案例。与上一同证明了DDL语句获取锁的顺序是字典序的
x 和 new_x 有相同的结构。再一次重复上述语句。
session1 LOCK TABLE x WRITE, new_x WRITE;
session2 INSERT INTO x VALUES(1);
session3 RENAME TABLE x TO old_x, new_x TO x;
session1 UNLOCK TABLES;
这时候，猜猜这个数据插入到哪里了。session3获得锁的顺序是new_x, x, old_x。而session2需要x锁。所以session2先插入记录到x中，然后x改名为old_x 。记录是在old_x中。
元数据锁的释放
为确保事务串行化，MySQL不得允许一个会话在另一个会话中未完成的显式或隐式启动的事务中使用的表上，执行数据定义语言（DDL）语句。服务器通过获取事务中使用的表的元数据锁并延迟释放这些锁直到事务结束来实现此目的。 表上的元数据锁可防止更改表的结构。 这种锁定方法的含义是，在事务结束之前，其他会话不能在DDL语句中使用一个会话中的事务正在使用的表。（译者废话：也就说，不允许在对一张表做操作过程中，表的结构被其他线程改了。这是很显然需要保护的）
这个规则不仅仅适用于事务表，对非事务表同样适用。假设一个会话以一个事务表 t 和一个非事务表 启动事务。如下：
START TRANSACTION; SELECT * FROM t; SELECT * FROM nt;
该会话持有t、nt的元数据锁，直到事务结束。如果有其他线程尝试在这两个表上做一个DDL语句（exclusive lock）或者write lock操作。比如，下面的语句都会被堵塞
DROP TABLE t; ALTER TABLE t ...; DROP TABLE nt; ALTER TABLE nt ...; LOCK TABLE t ... WRITE;
同样的行为适用于LOCK TABLES ... READ。 也就是说，更新任何表（事务性或非事务性）的显式或隐式启动事务将被阻塞。
如果服务获取语法有效但在执行期间失败的语句的元数据锁，则它不会提前释放锁（“译者注：比如插入冲突”）。 锁定释放仍然延迟到事务结束，因为失败的语句被写入二进制日志，并且锁定保护日志一致性。
在autocommit = true 的情况下，语句执行完，元数据锁就释放了。
在prepare语句后，即使在多语句事务中进行prepare，也会释放PREPARE语句期间获取的元数据锁。
