Metadata Locking Client 3: The statement requests exclusive locks in name order on  new_x ,  old_x , and  x , but blocks waiting for the lock on  new_x . Client 1: The statement releases the write locks on  x  and  new_x . For  x , the only pending request is by Client 2, so Client 2 acquires its lock, performs the insert, and releases the lock. For  new_x , the only pending request is by Client 3, which is permitted to acquire that lock (and also the lock on  old_x ). The rename operation still blocks for the lock on  x  until the Client 2 insert finishes and releases its lock. Then Client 3 acquires the lock on  x , performs the rename, and releases its lock. In this case, lock acquisition order results in the  INSERT  executing before the  RENAME TABLE . The  x  into which the insert occurs is the original  x , now renamed to  old_x  by the rename operation: If order of lock acquisition in concurrent statements makes a difference to an application in operation outcome, as in the preceding example, you may be able to adjust the table names to affect the order of lock acquisition. Metadata locks are extended, as necessary, to tables related by a foreign key constraint to prevent conflicting DML and DDL operations from executing concurrently on the related tables. When updating a parent table, a metadata lock is taken on the child table while updating foreign key metadata. Foreign key metadata is owned by the child table. To ensure transaction serializability, the server must not permit one session to perform a data definition language (DDL) statement on a table that is used in an uncompleted explicitly or implicitly started transaction in another session. The server achieves this by acquiring metadata locks on tables used within a transaction and deferring release of those locks until the transaction ends. A metadata lock on a table prevents changes to the table’s structure. This locking approach has the implication that a table that is being used by a transaction within one session cannot be used in DDL statements by other sessions until the transaction ends. This principle applies not only to transactional tables, but also to nontransactional tables. Suppose that a session begins a transaction that uses transactional table  t  and nontransactional table  nt  as follows: The server holds metadata locks on both  t  and  nt  until the transaction ends. If another session attempts a DDL or write lock operation on either table, it blocks until metadata lock release at transaction end. For example, a second session blocks if it attempts any of these operations: 1829 START TRANSACTION; SELECT * FROM t; SELECT * FROM nt; mysql>  SELECT * FROM x; Empty set (0.01 sec) mysql>  SELECT * FROM old_x; +------+ | i | +------+ | 1 | +------+ UNLOCK TABLES; RENAME TABLE x TO old_x, new_x TO x; Metadata Lock Release