13.7.8.3 FLUSH 语句_MySQL 8.0 参考手册

MySQL 8.0 参考手册 / 第 13 章 SQL 语句 / 13.7 数据库管理语句 / 13.7.8 其他行政报表 / 13.7.8.3 FLUSH 语句

13.7.8.3 FLUSH 语句

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在存储过程中使用，只要这些不是从存储函数或触发器中调用的。请参阅第 25.8 节，“对存储程序的限制”。

默认情况下，服务器将 FLUSH语句写入二进制日志，以便它们复制到副本。要禁止记录日志，请指定可选NO_WRITE_TO_BINLOG 关键字或其别名LOCAL。

笔记

FLUSH LOGS, FLUSH BINARY LOGS, FLUSH TABLES WITH READ LOCK （有或没有表列表），并且在任何情况下都不会写入二进制日志，因为如果复制到副本，它们会导致问题。 FLUSH TABLES tbl_name ... FOR EXPORT

该FLUSH语句导致隐式提交。请参阅第 13.3.3 节，“导致隐式提交的语句”。

mysqladmin实用程序使用flush-hosts、 flush-logs、 flush-privileges、 flush-status和等命令为某些刷新操作提供命令行界面flush-tables。请参阅第 4.5.2 节，“mysqladmin — 一个 MySQL 服务器管理程序”。

向服务器发送SIGHUPor SIGUSR1信号会导致发生多个刷新操作，这些操作类似于各种形式的FLUSH语句。信号可以由root系统帐户或拥有服务器进程的系统帐户发送。这使得刷新操作无需连接到服务器即可执行，这需要一个 MySQL 帐户具有足够的权限来执行这些操作。请参阅第 4.10 节，“MySQL 中的 Unix 信号处理”。

声明RESET类似于。有关使用复制的信息，FLUSH请参阅第 13.7.8.6 节，“RESET 语句” 。RESET

以下列表描述了允许的 FLUSH语句 flush_option值。有关允许tables_option 值的说明，请参阅FLUSH TABLES 语法。

FLUSH BINARY LOGS
关闭并重新打开服务器正在写入的任何二进制日志文件。如果启用了二进制日志记录，则二进制日志文件的序列号相对于前一个文件递增 1。
此操作需要 RELOAD特权。
FLUSH ENGINE LOGS
关闭并重新打开已安装存储引擎的任何可刷新日志。这导致InnoDB将其日志刷新到磁盘。
此操作需要 RELOAD特权。
FLUSH ERROR LOGS
关闭并重新打开服务器正在写入的任何错误日志文件。
此操作需要 RELOAD特权。
FLUSH GENERAL LOGS
关闭并重新打开服务器正在写入的任何常规查询日志文件。
此操作需要 RELOAD特权。
此操作对用于通用查询日志的表没有影响（请参阅第 5.4.1 节，“选择通用查询日志和慢速查询日志输出目标”）。
FLUSH HOSTS
清空主机缓存和 host_cache公开缓存内容的性能模式表，并取消阻止任何被阻止的主机。
此操作需要 RELOAD特权。
有关为什么建议或希望刷新主机缓存的信息，请参阅第 5.1.12.3 节，“DNS 查找和主机缓存”。
笔记

FLUSH HOSTS从 MySQL 8.0.23 开始弃用；希望在未来的 MySQL 版本中将其删除。相反，截断性能模式 host_cache表：
```
TRUNCATE TABLE performance_schema.host_cache;
```
该TRUNCATE TABLE 操作需要DROP 表的特权而不是 RELOAD特权。您应该知道该TRUNCATE TABLE 语句不会写入二进制日志。要从获得相同的行为FLUSH HOSTS，请指定 NO_WRITE_TO_BINLOG或 LOCAL作为语句的一部分。
FLUSH LOGS
关闭并重新打开服务器正在写入的任何日志文件。
此操作需要 RELOAD特权。
此操作的效果等同于这些操作的组合效果：
```
FLUSH BINARY LOGS
FLUSH ENGINE LOGS
FLUSH ERROR LOGS
FLUSH GENERAL LOGS
FLUSH RELAY LOGS
FLUSH SLOW LOGS
```
FLUSH OPTIMIZER_COSTS
重新读取成本模型表，以便优化器开始使用存储在其中的当前成本估算。
此操作需要 FLUSH_OPTIMIZER_COSTS或 RELOAD特权。
对于任何无法识别的成本模型表条目，服务器都会将警告写入错误日志。有关这些表的信息，请参阅第 8.9.5 节，“优化器成本模型”。此操作仅影响在刷新之后开始的会话。现有会话继续使用开始时的最新成本估算。
FLUSH PRIVILEGES
mysql从系统架构中的授权表中重新读取权限。作为此操作的一部分，服务器读取 global_grants包含动态权限分配的表并注册在那里找到的任何未注册的权限。
仅当您直接对授权表进行此类更改时，才需要重新加载授权表以启用对 MySQL 权限和用户的更新；GRANT或等账户管理报表不需要它 REVOKE，它会立即生效。有关详细信息，请参阅第 6.2.13 节，“权限更改何时生效”。
此操作需要 RELOAD特权。
如果--skip-grant-tables 在服务器启动时指定该选项以禁用 MySQL 特权系统，则FLUSH PRIVILEGES提供一种在运行时启用特权系统的方法。
重置登录失败跟踪（或者如果服务器启动时启用它 --skip-grant-tables）并解锁任何临时锁定的帐户。请参阅第 6.2.15 节，“密码管理”。
释放由服务器缓存的内存作为 GRANT、 CREATE USER、 CREATE SERVER和 INSTALL PLUGIN语句的结果。此内存不会由相应 REVOKE的、 DROP USER、 DROP SERVER和 UNINSTALL PLUGIN语句释放，因此对于执行许多导致缓存的语句实例的服务器，缓存内存使用量会增加，除非使用释放它 FLUSH PRIVILEGES。
caching_sha2_password清除身份验证插件使用的内存缓存。请参阅 SHA-2 可插入身份验证的缓存操作。
FLUSH RELAY LOGS [FOR CHANNEL channel]
关闭并重新打开服务器正在写入的任何中继日志文件。如果启用中继日志记录，则中继日志文件的序列号相对于前一个文件递增 1。
此操作需要 RELOAD特权。
该子句使您能够命名该操作适用于哪个复制通道。执行以刷新特定复制通道的中继日志。如果没有命名通道并且不存在额外的复制通道，则该操作适用于默认通道。如果没有命名通道并且存在多个复制通道，则该操作适用于所有复制通道。有关详细信息，请参阅第 17.2.2 节，“复制通道”。 FOR CHANNEL channelFLUSH RELAY LOGS FOR CHANNEL channel
FLUSH SLOW LOGS
关闭并重新打开服务器正在写入的任何慢速查询日志文件。
此操作需要 RELOAD特权。
此操作对用于慢速查询日志的表没有影响（请参阅第 5.4.1 节，“选择通用查询日志和慢速查询日志输出目标”）。
FLUSH STATUS
刷新状态指示器。
此操作将当前线程的会话状态变量值添加到全局值并将会话值重置为零。一些全局变量也可能被重置为零。它还将密钥缓存（默认和命名）的计数器重置为零，并设置 Max_used_connections为当前打开的连接数。此信息在调试查询时可能有用。请参阅第 1.6 节，“如何报告错误或问题”。
FLUSH STATUS不受 read_onlyor 的影响super_read_only，并且始终写入二进制日志。
此操作需要 FLUSH_STATUS或 RELOAD特权。
FLUSH USER_RESOURCES
将所有每小时用户资源指标重置为零。
此操作需要 FLUSH_USER_RESOURCES或 RELOAD特权。
重置资源指示器使已达到每小时连接、查询或更新限制的客户端能够立即恢复活动。FLUSH USER_RESOURCES不适用于由 max_user_connections系统变量控制的最大同时连接数限制。请参阅第 6.2.21 节，“设置帐户资源限制”。

刷新表语法

FLUSH TABLES刷新表，并根据使用的变体获取锁。语句中使用的任何 TABLES变体 FLUSH必须是唯一使用的选项。FLUSH TABLE是的同义词FLUSH TABLES。

笔记

此处指示通过关闭表来刷新表的描述不同地适用于InnoDB，它将表内容刷新到磁盘但使它们保持打开状态。这仍然允许在表打开时复制表文件，只要其他活动不修改它们即可。

FLUSH TABLES
关闭所有打开的表，强制关闭所有正在使用的表，并刷新准备好的语句缓存。
此操作需要 FLUSH_TABLES或 RELOAD特权。
有关准备语句缓存的信息，请参阅第 8.10.3 节，“准备语句和存储程序的缓存”。
FLUSH TABLES存在活动时不允许 LOCK TABLES ... READ。要刷新和锁定表，请改用。 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。UNLOCK TABLES后续不会发生提交， FLUSH TABLES WITH READ LOCK因为后面的语句不获取表锁。
- 开始一个事务会导致获得的表锁 LOCK TABLES被释放，就好像你已经执行了一样 UNLOCK TABLES。开始事务不会释放使用获取的全局读锁 FLUSH TABLES WITH READ LOCK。
FLUSH TABLES WITH READ LOCK 不会阻止服务器将行插入日志表（请参阅第 5.4.1 节，“选择一般查询日志和慢速查询日志输出目的地”）。
FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK
刷新并获取命名表的读锁。
此操作需要 FLUSH_TABLES或 RELOAD特权。因为它获取表锁，所以它还需要 LOCK TABLES每个表的权限。
该操作首先获取表的独占元数据锁，因此它等待打开这些表的事务完成。然后该操作从表缓存中刷新表，重新打开表，获取表锁（如 LOCK TABLES ... READ），并将元数据锁从独占降级为共享。操作获取锁并降级元数据锁后，其他会话可以读取但不能修改表。
此操作仅适用于现有基（非TEMPORARY) 表）。如果名称引用基表，则使用该表。如果它引用 TEMPORARY表，则忽略它。如果名称适用于视图， ER_WRONG_OBJECT则会发生错误。否则, 发生 ER_NO_SUCH_TABLE错误。
用于UNLOCK TABLES释放锁， LOCK TABLES释放锁并获取其他锁，或 START TRANSACTION释放锁并开始新的事务。
此FLUSH TABLES变体使表能够在单个操作中被刷新和锁定。FLUSH TABLES它为存在活动时不允许的限制提供了解决方法 LOCK TABLES ... READ。
此操作不执行隐式操作 UNLOCK TABLES，因此如果您在有任何活动的情况下执行操作 LOCK TABLES或在没有首先释放获取的锁的情况下再次使用它，则会导致错误。
如果使用打开刷新表 HANDLER，处理程序将被隐式刷新并失去其位置。
FLUSH TABLES tbl_name [, tbl_name] ... FOR EXPORT
此FLUSH TABLES变体适用于InnoDB表格。它确保对命名表的更改已刷新到磁盘，以便可以在服务器运行时创建二进制表副本。
此操作需要 FLUSH_TABLES或 RELOAD特权。因为它获取表上的锁以准备导出它们，所以它还需要每个表的LOCK TABLES和SELECT 特权。
操作是这样的：
1. 它获取命名表的共享元数据锁。只要其他会话具有已修改这些表或为它们持有表锁的活动事务，该操作就会阻塞。获取锁后，该操作会阻止尝试更新表的事务，同时允许只读操作继续进行。
2. 它检查表的所有存储引擎是否支持FOR EXPORT. 如果没有， ER_ILLEGAL_HA则会发生错误并且操作失败。
3. 该操作通知每个表的存储引擎使表准备好导出。存储引擎必须确保任何挂起的更改都写入磁盘。
4. 该操作将会话置于锁表模式，以便在FOR EXPORT 操作完成时不会释放先前获取的元数据锁。
此操作仅适用于现有基（非TEMPORARY）表。如果名称引用基表，则使用该表。如果它引用一个 TEMPORARY表，它会被忽略。如果名称应用于视图， ER_WRONG_OBJECT则会发生错误。否则， ER_NO_SUCH_TABLE会发生错误。
InnoDB支持FOR EXPORT具有自己的 .ibd 文件文件的表（即，在 innodb_file_per_table 启用设置的情况下创建的表）。InnoDB确保在FOR EXPORT操作通知任何更改已刷新到磁盘时。这允许在FOR EXPORT操作生效时制作表内容的二进制副本，因为该 .ibd文件是事务一致的并且可以在服务器运行时复制。FOR EXPORT不适用于InnoDB 系统表空间文件或InnoDB 具有FULLTEXT索引的表。
FLUSH TABLES ...FOR EXPORT分区 InnoDB表支持。
当通知时FOR EXPORT， InnoDB将通常保存在内存中或表空间文件外的单独磁盘缓冲区中的某些类型的数据写入磁盘。对于每个表， InnoDB还会 table_name.cfg 在与表相同的数据库目录中生成一个文件。该 .cfg文件包含稍后将表空间文件重新导入相同或不同服务器所需的元数据。
当FOR EXPORT操作完成时，已将所有脏页InnoDB刷新到表数据文件中。在刷新之前合并任何更改缓冲区条目。此时，表被锁定并处于静止状态：表在磁盘上处于事务一致状态，您可以复制表空间文件以及相应的文件以获得这些表的一致快照。 .ibd.cfg
有关将复制的表数据重新导入 MySQL 实例的过程，请参阅第 15.6.1.3 节，“导入 InnoDB 表”。
处理完表后，使用 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
```