FLUSH [NO_WRITE_TO_BINLOG | LOCAL] {
flush_option [, flush_option] ...
| tables_option
}
flush_option: {
BINARY LOGS
| ENGINE LOGS
| ERROR LOGS
| GENERAL LOGS
| HOSTS
| LOGS
| PRIVILEGES
| OPTIMIZER_COSTS
| RELAY LOGS [FOR CHANNEL channel]
| SLOW LOGS
| STATUS
| USER_RESOURCES
}
tables_option: {
TABLES
| TABLES tbl_name [, tbl_name] ...
| TABLES WITH READ LOCK
| TABLES tbl_name [, tbl_name] ... WITH READ LOCK
| TABLES tbl_name [, tbl_name] ... FOR EXPORT
}
FLUSH 语句有几种不同的形式，可以清除或重新加载各种内部缓存、刷新表或获取锁。每个 FLUSH 操作都需要其描述中指定的权限。无法在存储函数或触发器中执行 FLUSH 语句。但是，可以在存储过程中使用 FLUSH，只要这些过程不是从存储函数或触发器调用的。默认情况下，服务器将 FLUSH 语句写入二进制日志，以便它们复制到副本。要禁止记录到日志，请指定可选的 NO_WRITE_TO_BINLOG 关键字或其别名 LOCAL。FLUSH LOGS、FLUSH BINARY LOGS、FLUSH TABLES WITH READ LOCK（带或不带表列表）和 FLUSH TABLES tbl_name ... FOR EXPORT 在任何情况下都不会写入二进制日志，因为如果复制到副本中，它们会导致问题。mysqladmin 实用程序使用诸如 flush-hosts、flush-logs、flush-privileges、flush-status 和 flush-tables 之类的命令，为某些刷新操作提供了命令行接口。向服务器发送 SIGHUP 或 SIGUSR1 信号会导致发生多个刷新操作，这些操作类似于 FLUSH 语句的各种形式。信号可以由 root 系统帐户或拥有服务器进程的系统帐户发送。这样就可以在不必连接到服务器的情况下执行刷新操作，执行这些操作需要具有足够权限的 MySQL 帐户。以下列表描述了允许的 FLUSH 语句的 flush_option 值。有关允许的 tables_option 值的说明，请参阅 FLUSH TABLES 语法。关闭并重新打开服务器正在写入的二进制日志文件。如果启用了二进制日志记录，则二进制日志文件的序列号相对于上一个文件增加一。关闭并重新打开已安装存储引擎的所有可刷新日志。这会导致 InnoDB 将其日志刷新到磁盘。清空主机缓存和显示缓存内容的 Performance Schema host_cache 表，并解锁任何被阻止的主机。从 MySQL 8.0.23 开始，就不推荐使用 FLUSH HOSTS 了；在将来的 MySQL版 本中有望删除。目前推荐删除 Performance Schema host_cache 表：TRUNCATE TABLE performance_schema.host_cache;
TRUNCATE TABLE 操作需要表的 DROP 权限，而不是 RELOAD 权限。FLUSH BINARY LOGS
FLUSH ENGINE LOGS
FLUSH ERROR LOGS
FLUSH GENERAL LOGS
FLUSH RELAY LOGS
FLUSH SLOW LOGS
重新读取成本模型表，以便优化器开始使用存储在其中的当前成本估算。此操作需要 FLUSH_OPTIMIZER_COSTS 或 RELOAD 权限。对于任何无法识别的成本模型表条目，服务器会将警告写入错误日志。此操作仅影响刷新之后开始的会话。现有会话继续使用开始时的成本估算。从 mysql 系统模式中的授权表中重新读取权限。作为此操作的一部分，服务器读取包含动态权限分配的 global_grants 表，并在该表中注册找到的未注册权限。如果在服务器启动时指定 --skip-grant-tables 选项以禁用 MySQL 权限系统，则 FLUSH PRIVILEGES 提供了一种在运行时启用权限系统的方法。重置失败登录跟踪（或者如果服务器启动时使用 --skip-grant-tables，启用它）并解锁所有临时锁定的帐户。释放 GRANT、CREATE USER、CREATE SERVER 和 INSTALL PLUGIN 语句引起的服务器缓存内存。对应的 REVOKE、DROP USER、DROP SERVER 和 UNINSTALL PLUGIN 语句引起的内存缓存不会释放，因此对于执行许多导致缓存的语句的服务器，除非使用 FLUSH PRIVILEGES 释放缓存内存，否则会增加缓存内存的使用。清除 caching_sha2_password 身份验证插件使用的内存缓存。● FLUSH RELAY LOGS [FOR CHANNEL channel]关闭并重新打开服务器正在写入的中继日志文件。如果启用了中继日志记录，则中继日志文件的序列号将相对于上一个文件增加1。FOR CHANNEL channel 子句允许指定操作应用于哪个复制通道。执行 FLUSH RELAY LOGS FOR CHANNEL channel 以刷新指定复制通道的中继日志。如果没有指定通道，并且不存在额外的复制通道，则该操作将应用于默认通道。如果没有指定通道，并且存在多个复制通道，则该操作将应用于所有复制通道。此操作需要 FLUSH_STATUS 或 RELOAD 权限。此操作将所有活动会话的会话状态添加到全局状态变量中，重置所有活动会话的状态，并重置从断开连接的会话聚合的帐户、主机和用户状态值。此操作需要 FLUSH_USER_RESOURCES 或 RELOAD 权限。重置资源指示器使达到每小时连接、查询或更新限制的客户端能够立即恢复活动。FLUSH USER_RESOURCES 不适用于由 max_user_connections 系统变量控制的最大同时连接数限制。FLUSH TABLES 刷新表，并根据使用的形式获取锁。FLUSH 语句中使用的任何 TABLES 变体都必须是唯一使用的选项。FLUSH TABLE 是 FLUSH TABLES 的同义词。这里通过关闭表来刷新表的描述对 InnoDB 不适用，InnoDB 将表内容刷新到磁盘，但表保持打开状态。允许在表打开时复制表文件，只要其他活动不修改它们。关闭所有打开的表，强制关闭所有正在使用的表，并刷新预编译语句缓存。此操作需要 FLUSH_TABLES 或 RELOAD 权限。当存在活动的 LOCK TABLES ... READ 时，不允许 FLUSH TABLES。要刷新和锁定表，请使用 FLUSH TABLES tbl_name ... WITH READ LOCK 代替。● FLUSH TABLES tbl_name [, tbl_name] ...带有逗号分隔的表名列表，此操作类似于不带表名的 FLUSH TABLES 语句，只是服务器只刷新指定的表。如果指定表不存在，不会发生错误。此操作需要 FLUSH_TABLES 或 RELOAD 权限。● FLUSH TABLES WITH READ LOCK关闭所有打开的表，并使用全局读锁锁定所有数据库的所有表。此操作需要 FLUSH_TABLES 或 RELOAD 权限。如果文件系统（如 Veritas 或 ZFS）可以及时获取快照，则此操作是获取备份的一种非常方便的方法。使用 UNLOCK TABLES 释放锁。FLUSH TABLES WITH READ LOCK 会获取全局读锁，而不是表锁，因此在表锁定和隐式提交方面，它与 LOCK TABLES 和 UNLOCK TABLES 的行为不同：■ UNLOCK TABLES 仅当表当前已通过 LOCK TABLES 锁定时，才隐式提交活动事务。对于 FLUSH TABLES WITH READ LOCK 之后的 UNLOCK TABLES，不会发生提交，因为前面的语句不会获取表锁。■ 开始一个事务会释放通过 LOCK TABLES 获取的表锁，就像执行了 UNLOCK TABLES 一样。开始事务不会释放通过 FLUSH TABLES WITH READ LOCK 获取的全局读锁。FLUSH TABLES WITH READ LOCK 不会阻止服务器将行插入到日志表中。● FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK此操作需要 FLUSH_TABLES 或 RELOAD 权限。因为它获取表锁，所以它还需要每个表的 LOCK TABLES 权限。操作首先获取表的独占元数据锁，因此它等待打开这些表的事务完成。然后操作从表缓存中刷新表，重新打开表，获取表锁（类似于 LOCK TABLES ... READ），并将元数据锁从独占降级为共享。在操作获取锁并降级元数据锁之后，其他会话可以读取但不能修改表。此操作仅适用于现有的基本（非临时）表。如果名称引用了基本表，则使用该表。如果它引用一个 TEMPORARY 表，它将被忽略。如果名称是视图，就会出现 ER_WRONG_OBJECT 错误。否则，会发生 ER_NO_SUCH_TABLE 错误。使用 UNLOCK TABLES 释放锁，使用 LOCK TABLES 释放锁并获取其他锁，使用 START TRANSACTION 释放锁并开始新事务。这种 FLUSH TABLES 变体允许在单个操作中刷新和锁定表。当存在活动 LOCK TABLES ... READ 时不允许 FLUSH TABLES，对于这种限制，它提供了一种解决方法。此操作不执行隐式 UNLOCK TABLES，因此如果在存在任何活动 LOCK TABLES 的情况下执行此操作或在未首先释放获取的锁的情况下再次使用此操作，则会导致错误。如果用 HANDLER 打开刷新的表，则句柄将被隐式刷新并丢失其位置。● FLUSH TABLES tbl_name [, tbl_name] ... FOR EXPORT这种 FLUSH TABLES 变体适用于 InnoDB 表。它确保已将对指定表的更改刷新到磁盘，以便在服务器运行时制作二进制表副本。此操作需要 FLUSH_TABLES 或 RELOAD 权限。因为它获取表上的锁以准备导出它们，所以它还需要每个表的 LOCK TABLES 和 SELECT 权限。a. 它获取指定表的共享元数据锁。只要其他会话具有已修改这些表的活动事务，或持有表锁的活动事务，操作就会阻塞。获取锁后，将阻止尝试更新表的事务，同时允许只读操作继续。b. 它检查表的所有存储引擎是否都支持 FOR EXPORT。如果不是，则会发生 ER_ILLEGAL_HA 错误，操作失败。c. 该操作通知每个表的存储引擎，使该表准备好导出。存储引擎必须确保将任何挂起的更改写入磁盘。d. 该操作将会话置于锁表模式，以便在 FOR EXPORT 操作完成时不会释放先前获取的元数据锁。此操作仅适用于现有的基本（非临时）表。如果名称引用基本表，则使用该表。如果引用临时表，它将被忽略。如果引用视图，就会出现 ER_WRONG_OBJECT 错误。否则，会发生 ER_NO_SUCH_TABLE 错误。对于具有自己的 .ibd 文件的表（即，启用了 innodb_file_per_table 设置创建的表），InnoDB 支持 FOR EXPORT。InnoDB 会确保当 FOR EXPORT 操作通知时，任何更改都已刷新到磁盘。这允许在 FOR EXPORT 操作生效时生成表内容的二进制副本，因为 .ibd 文件是事务一致的，可以在服务器运行时进行复制。FOR EXPORT 不适用于 InnoDB 系统表空间文件，也不适用于具有 FULLTEXT 索引的 InnoDB 表。分区的 InnoDB 表支持 FLUSH TABLES ...FOR EXPORT。当收到 FOR EXPORT 通知时，InnoDB 将某些类型的数据写入磁盘，这些数据通常保存在内存中或表空间文件之外的单独磁盘缓冲区中。对于每个表，InnoDB 还在与表数据库相同的目录中生成一个名为 table_name.cfg 的文件。.cfg 文件包含以后将表空间文件重新导入相同或不同服务器所需的元数据。当 FOR EXPORT 操作完成时，InnoDB 已将所有脏页刷新到表数据文件中。任何更改缓冲区条目都会在刷新之前合并。此时，表被锁定并处于静止状态：表在磁盘上处于事务一致状态，可以将 .ibd 表空间文件与相应的 .cfg 文件一起复制，以获得这些表的一致快照。处理完表后，使用 UNLOCK TABLES 释放锁，LOCK TABLES 释放锁并获取其他锁，START TRANSACTION 释放锁并开始新的事务。当这些语句中的任何一个在会话中有效时，尝试使用 FLUSH TABLES ... FOR EXPORT 会引发错误：FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
LOCK TABLES ... READ
LOCK TABLES ... WRITE
当 FLUSH TABLES ... FOR EXPORT 在会话中有效时，尝试使用这些语句都会产生错误：FLUSH TABLES WITH READ LOCK
FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
https://dev.mysql.com/doc/refman/8.0/en/flush.html
