FLUSH [LOCAL | NO_WRITE_TO_BINLOG]
flush_option [, flush_option] ...
The FLUSH statement clears or reloads various
internal caches used by MySQL. To execute
FLUSH, you must have the
RELOAD privilege.
The RESET statement is similar to
FLUSH. See Section 12.5.6.5, “RESET Syntax”.
flush_option can be any of the
following:
DES_KEY_FILE
Reloads the DES keys from the file that was specified with
the --des-key-file option at server startup
time.
HOSTS
Empties the host cache tables. You should flush the host
tables if some of your hosts change IP number or if you get
the error message Host
'.
When more than host_name' is blockedmax_connect_errors errors
occur successively for a given host while connecting to the
MySQL server, MySQL assumes that something is wrong and
blocks the host from further connection requests. Flushing
the host tables enables further connection attempts from the
host. See Section B.1.2.6, “Host '”. You can start
mysqld with
host_name' is
blocked--max_connect_errors=999999999 to avoid
this error message.
LOGS
Closes and reopens all log files. If binary logging is
enabled, the sequence number of the binary log file is
incremented by one relative to the previous file. On Unix,
this is the same thing as sending a
SIGHUP signal to the
mysqld server (except on some Mac OS X
10.3 versions where mysqld ignores
SIGHUP and SIGQUIT).
If the server is writing error output to a named file (for
example, if it was started with the
--log-error option), FLUSH
LOGS causes it to rename the current error log
file with a suffix of -old and create a
new empty log file. No renaming occurs if the server is not
writing to a named file (for example, if it is writing
errors to the console).
MASTER (DEPRECATED).
Deletes all binary logs, resets the binary log index file
and creates a new binary log. FLUSH
MASTER is deprecated in favor of RESET
MASTER, and is supported for backward
compatibility only. See Section 12.6.1.2, “RESET MASTER Syntax”.
PRIVILEGES
Reloads the privileges from the grant tables in the
mysql database. On Unix, this also occurs
if the server receives a SIGHUP signal.
The server caches information in memory as a result of
GRANT, CREATE USER,
CREATE SERVER, and INSTALL
PLUGIN statements. This memory is not released by
the corresponding REVOKE, DROP
USER, DROP SERVER, and
UNINSTALL PLUGIN statements, so for a
server that executes many instances of the statements that
cause caching, there will be an increase in memory use. This
cached memory can be freed with FLUSH
PRIVILEGES.
QUERY CACHE
Defragment the query cache to better utilize its memory.
FLUSH QUERY CACHE does not remove any
queries from the cache, unlike FLUSH
TABLES or RESET QUERY CACHE.
SLAVE (DEPRECATED).
Resets all replication slave parameters, including relay log
files and replication position in the master's binary logs.
FLUSH SLAVE is deprecated in favor of
RESET SLAVE, and is supported for
backward compatibility only. See
Section 12.6.2.5, “RESET SLAVE Syntax”.
STATUS
This option adds the current thread's session status
variable values to the global values and resets the session
values to zero. It also resets the counters for key caches
(default and named) to zero and sets
Max_used_conections to the current number
of open connections. This is something you should use only
when debugging a query. See Section 1.7, “How to Report Bugs or Problems”.
{TABLE | TABLES}
[
tbl_name [,
tbl_name] ...]
When no tables are named, closes all open tables, forces all
tables in use to be closed, and flushes the query cache.
With one or more table names, flushes only the given tables.
FLUSH TABLES also removes all query
results from the query cache, like the RESET QUERY
CACHE statement.
TABLES WITH READ LOCK
Closes all open tables and locks all tables for all
databases with a read lock until you explicitly release the
lock by executing UNLOCK TABLES. This is
very convenient way to get backups if you have a filesystem
such as Veritas that can take snapshots in time.
FLUSH TABLES WITH READ LOCK acquires a
global read lock and not 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:
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.
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.
USER_RESOURCES
Resets all per-hour user resources to zero. This enables
clients that have reached their hourly connection, query, or
update limits to resume activity immediately. FLUSH
USER_RESOURCES does not apply to the limit on
maximum simultaneous connections. See
Section 12.5.1.3, “GRANT Syntax”.
By default, FLUSH statements are written to
the binary log. Such statements used on a MySQL server acting as
a replication master will be replicated to replication slaves.
Logging can be suppressed with the optional
NO_WRITE_TO_BINLOG keyword or its alias
LOCAL.
See also Section 12.5.6.5, “RESET Syntax”, for information about how the
RESET statement is used with replication.
FLUSH LOGS, FLUSH
MASTER, FLUSH SLAVE, and
FLUSH TABLES WITH READ LOCK are not written
to the binary log in any case because they would cause
problems if replicated to a slave.
The mysqladmin utility provides a
command-line interface to some flush operations, via the
flush-hosts, flush-logs,
flush-privileges,
flush-status, and
flush-tables commands.
It is not possible in MySQL 5.1 to issue
FLUSH statements within stored functions or
triggers. However, you may use FLUSH in
stored procedures, so long as these are not called from stored
functions or triggers. See
Section D.1, “Restrictions on Stored Routines, Triggers, and Events”.

User Comments
Add your own comment.