Other Administrative Statements This operation requires the  FLUSH_TABLES  or  RELOAD  privilege. Closes all open tables and locks all tables for all databases with a global read lock. This operation requires the  FLUSH_TABLES  or  RELOAD  privilege. This operation is a very convenient way to get backups if you have a file system such as Veritas or ZFS that can take snapshots in time. Use  UNLOCK TABLES  to release the lock. FLUSH TABLES WITH READ LOCK  acquires a global read lock rather than table locks, so it is not subject to the same behavior as  LOCK TABLES  and  UNLOCK TABLES  with respect to table locking and implicit commits: FLUSH TABLES WITH READ LOCK  does not prevent the server from inserting rows into the log tables (see Section 5.4.1, “Selecting General Query Log and Slow Query Log Output Destinations” ). Flushes and acquires read locks for the named tables. This operation requires the  FLUSH_TABLES  or  RELOAD  privilege. Because it acquires table locks, it also requires the  LOCK TABLES  privilege for each table. The operation first acquires exclusive metadata locks for the tables, so it waits for transactions that have those tables open to complete. Then the operation flushes the tables from the table cache, reopens the tables, acquires table locks (like  LOCK TABLES ... READ ), and downgrades the metadata locks from exclusive to shared. After the operation acquires locks and downgrades the metadata locks, other sessions can read but not modify the tables. This operation applies only to existing base (non- TEMPORARY)  tables. If a name refers to a base table, that table is used. If it refers to a  TEMPORARY  table, it is ignored. If a name applies to a view, an ER_WRONG_OBJECT  error occurs. Otherwise, an  ER_NO_SUCH_TABLE  error occurs. Use  UNLOCK TABLES  to release the locks,  LOCK TABLES  to release the locks and acquire other locks, or  START TRANSACTION  to release the locks and begin a new transaction. This  FLUSH TABLES  variant enables tables to be flushed and locked in a single operation. It provides a workaround for the restriction that  FLUSH TABLES  is not permitted when there is an active  LOCK TABLES ... READ . This operation does not perform an implicit  UNLOCK TABLES , so an error results if you perform the operation while there is any active  LOCK TABLES  or use it a second time without first releasing the locks acquired. If a flushed table was opened with  HANDLER , the handler is implicitly flushed and loses its position. 2975 • FLUSH TABLES  tbl_name  [,  tbl_name ] ... WITH READ LOCK •Beginning a transaction causes table locks acquired with  LOCK TABLES  to be released, as though you had executed  UNLOCK TABLES . Beginning a transaction does not release a global read lock acquired with  FLUSH TABLES WITH READ LOCK . • UNLOCK TABLES  implicitly commits any active transaction only if any tables currently have been locked with  LOCK TABLES . The commit does not occur for  UNLOCK TABLES  following  FLUSH TABLES WITH READ LOCK  because the latter statement does not acquire table locks. • FLUSH TABLES WITH READ LOCK