Metadata Locking GET_LOCK()  function (see Section 12.15, “Locking Functions” ), and locks acquired with the locking service described in Section 5.6.9.1, “The Locking Service” . The Performance Schema  metadata_locks  table exposes metadata lock information, which can be useful for seeing which sessions hold locks, are blocked waiting for locks, and so forth. For details, see Section 27.12.13.3, “The metadata_locks Table” . Metadata locking does involve some overhead, which increases as query volume increases. Metadata contention increases the more that multiple queries attempt to access the same objects. Metadata locking is not a replacement for the table definition cache, and its mutexes and locks differ from the  LOCK_open  mutex. The following discussion provides some information about how metadata locking works. •Metadata Lock Acquisition •Metadata Lock Release If there are multiple waiters for a given lock, the highest-priority lock request is satisfied first, with an exception related to the  max_write_lock_count  system variable. Write lock requests have higher priority than read lock requests. However, if  max_write_lock_count  is set to some low value (say, 10), read lock requests may be preferred over pending write lock requests if the read lock requests have already been passed over in favor of 10 write lock requests. Normally this behavior does not occur because  max_write_lock_count  by default has a very large value. Statements acquire metadata locks one by one, not simultaneously, and perform deadlock detection in the process. DML statements normally acquire locks in the order in which tables are mentioned in the statement. DDL statements,  LOCK TABLES , and other similar statements try to reduce the number of possible deadlocks between concurrent DDL statements by acquiring locks on explicitly named tables in name order. Locks might be acquired in a different order for implicitly used tables (such as tables in foreign key relationships that also must be locked). For example,  RENAME TABLE  is a DDL statement that acquires locks in name order: •This  RENAME TABLE  statement renames  tbla  to something else, and renames  tblc  to  tbla : RENAME TABLE tbla TO tbld, tblc TO tbla; The statement acquires metadata locks, in order, on  tbla ,  tblc , and  tbld  (because  tbld  follows tblc  in name order): In this case, the statement acquires metadata locks, in order, on  tbla ,  tblb , and  tblc  (because  tblb precedes  tblc  in name order): Both statements acquire locks on  tbla  and  tblc , in that order, but differ in whether the lock on the remaining table name is acquired before or after  tblc . Metadata lock acquisition order can make a difference in operation outcome when multiple transactions execute concurrently, as the following example illustrates. •This slightly different statement also renames  tbla  to something else, and renames  tblc  to  tbla : RENAME TABLE tbla TO tblb, tblc TO tbla; 1827 Metadata Lock Acquisition