MySQL :: MySQL 8.3 Reference Manual :: 15.7.8.3 FLUSH Statement

version 8.3

8.0 current
5.7

8.0 Japanese

MySQL 8.3 Reference Manual / ... / FLUSH Statement

15.7.8.3 刷新语句

FLUSH [NO_WRITE_TO_BINLOG | LOCAL] {
    flush_option [, flush_option] ...
  | tables_option
}

flush_option: {
    BINARY LOGS
  | ENGINE LOGS
  | ERROR LOGS
  | GENERAL LOGS
  | LOGS
  | PRIVILEGES
  | OPTIMIZER_COSTS
  | RELAY LOGS [FOR CHANNEL channel]
  | SLOW LOGS
  | STATUS
  | USER_RESOURCES
}

tables_option: {
    table_synonym
  | table_synonym tbl_name [, tbl_name] ...
  | table_synonym WITH READ LOCK
  | table_synonym tbl_name [, tbl_name] ... WITH READ LOCK
  | table_synonym tbl_name [, tbl_name] ... FOR EXPORT
}

table_synonym: {
    TABLE
  | TABLES
}

该 刷新 语句有多种变体形式，清除或重新加载各种内部缓存，刷新表或获取锁。每个 刷新 操作都需要在其描述中指定的权限。

Note

无法在存储函数或触发器中发出 刷新 语句。但是，您可以在存储过程中使用 刷新，只要这些过程不是从存储函数或触发器调用。请参阅第 27.8 节，“存储程序限制”。

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

Note

刷新日志、刷新二进制日志、刷新表 WITH 读锁（带或不带表列表）和刷新表 tbl_name ... FOR EXPORT 在任何情况下都不会写入二进制日志，因为它们如果复制到副本将引起问题。

该 刷新 语句会导致隐式提交。请参阅第 15.3.3 节，“隐式提交语句”。

该 mysqladmin 实用程序提供了命令行界面来执行一些刷新操作，使用命令如 flush-logs、flush-privileges、flush-status 和 flush-tables。请参阅第 6.5.2 节，“mysqladmin — MySQL 服务器管理程序”。

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

该 RESET 语句类似于 刷新。请参阅第 15.7.8.6 节，“RESET 语句”，了解使用 RESET 与复制的信息。

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

刷新二进制日志

关闭并重新打开服务器正在写入的任何二进制日志文件。如果启用了二进制日志记录，则相对于之前的文件，二进制日志文件的序列号将增加 1。

该操作需要 RELOAD 权限。
刷新引擎日志

关闭并重新打开安装的存储引擎的任何可刷新日志。这将导致 InnoDB 将其日志刷新到磁盘。

此操作需要 RELOAD 权限。
FLUSH ERROR LOGS

关闭并重新打开服务器写入的任何错误日志文件。

此操作需要 RELOAD 权限。
FLUSH GENERAL LOGS

关闭并重新打开服务器写入的任何通用查询日志文件。

此操作需要 RELOAD 权限。

此操作对通用查询日志表无影响（见第 7.4.1 节，“选择通用查询日志和慢查询日志输出目标”）。
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 权限。

服务器将为任何未识别的成本模型表条目写入错误日志。有关这些表的信息，请参见第 10.9.5 节，“优化器成本模型”。此操作仅影响后续会话，而不是现有会话，它们继续使用开始时的成本估算。
FLUSH PRIVILEGES

重新读取 MySQL 系统架构中的权限表中的权限。作为此操作的一部分，服务器读取包含动态权限分配的 global_grants 表，并注册其中找到的任何未注册权限。

重新加载权限表是必要的，以便启用 MySQL 权限和用户的更新，只有在直接更改权限表时才需要；这不是账户管理语句（如 GRANT 或 REVOKE）的效果立即生效。请参见第 8.2.13 节，“权限更改何时生效”，以获取更多信息。

此操作需要 RELOAD 权限。

如果在服务器启动时指定了 --skip-grant-tables 选项以禁用 MySQL 权限系统，则 FLUSH PRIVILEGES 提供了一种在运行时启用权限系统的方法。

重置失败的登录跟踪（或启用它，如果服务器以 --skip-grant-tables 启动），并解锁任何暂时锁定的账户。请参见第 8.2.15 节，“密码管理”。

释放服务器由于GRANT、CREATE USER、CREATE SERVER 和INSTALL PLUGIN 语句而缓存的内存。这部分内存不会被相应的REVOKE、DROP USER、DROP SERVER 和UNINSTALL PLUGIN 语句释放，除非使用FLUSH PRIVILEGES 释放。

清除身份验证插件使用的内存缓存。请参阅 SHA-2 可插拔身份验证缓存操作。
FLUSH RELAY LOGS [FOR CHANNEL channel]

关闭并重新打开服务器写入的中继日志文件。如果启用了中继日志记录，则中继日志文件的序列号将相对于之前的文件增加一。

该操作需要RELOAD 权限。

该FOR CHANNEL channel 子句允许您指定操作应用于哪个复制通道。执行FLUSH RELAY LOGS FOR CHANNEL channel 以刷新指定复制通道的中继日志。如果未指定通道且不存在额外的复制通道，则操作将应用于默认通道。如果未指定通道且存在多个复制通道，则操作将应用于所有复制通道。有关更多信息，请参阅第 19.2.2 节，“复制通道”。
FLUSH SLOW LOGS

关闭并重新打开服务器写入的慢查询日志文件。

该操作需要RELOAD 权限。

该操作对慢查询日志表（请参阅第 7.4.1 节，“选择通用查询日志和慢查询日志输出目标”）没有影响。
FLUSH STATUS

刷新状态指示器。

该操作将当前线程的会话状态变量值添加到全局值中，并将会话值重置为零。一些全局变量也可能被重置为零。此外，还将键缓存（默认和命名）计数器重置为零，并将Max_used_connections 设置为当前打开的连接数。这些信息可能在调试查询时有用。请参阅第 1.5 节，“如何报告错误或问题”。

FLUSH STATUS 不受read_only 或super_read_only 的影响，并总是写入二进制日志。

该操作需要FLUSH_STATUS 或RELOAD 权限。
FLUSH USER_RESOURCES

将所有每小时用户资源指示器重置为零。

该操作需要FLUSH_USER_RESOURCES 或RELOAD 权限。

重置资源指示器使客户端能够立即恢复活动，因为它们已经达到每小时连接、查询或更新限制。FLUSH USER_RESOURCES 不适用于由 max_user_connections 系统变量控制的最大同时连接限制。请参阅第 8.2.21 节，“设置帐户资源限制”。

FLUSH TABLES 语法

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

Note

这里的描述表明表被刷新关闭适用于 InnoDB，它刷新表内容到磁盘，但保持它们打开。这仍然允许在表文件被复制时不修改它们。

FLUSH TABLES

关闭所有打开的表，强制所有使用中的表关闭，并刷新预备语句缓存。

此操作需要 FLUSH_TABLES 或 RELOAD 权限。

有关预备语句缓存的信息，请参阅第 10.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不阻止服务器将行插入日志表（见第 7.4.1 节，“选择通用查询日志和慢查询日志输出目标”）。
FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK

刷新并获取指定表的读锁。

该操作需要FLUSH_TABLES或RELOAD权限。因为它获取表锁，因此还需要LOCK TABLES权限对于每个表。

该操作首先获取指定表的独占元数据锁，然后刷新表缓存，重新打开表，获取表锁（类似LOCK TABLES ... READ），然后将元数据锁从独占降级为共享。其他会话可以读取但不能修改表。

该操作仅适用于现有的基本（非临时）表。如果名称引用基本表，则使用该表。如果它引用临时表，则忽略该表。如果名称应用于视图，出现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打开，处理程序将隐式刷新并失去其位置。
刷新表 tbl_name [, tbl_name] ... FOR EXPORT

该 刷新表 变体适用于 InnoDB 表。它确保对命名表的更改已经刷新到磁盘，以便在服务器运行时可以制作二进制表副本。

该操作需要 刷新表 或 重新加载 权限。因为它在准备导出表时获取表锁，因此还需要 锁定表 和 选择 权限 для每个表。

该操作按照以下方式工作：
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 系统表空间文件或具有 FULLTEXT 索引的 InnoDB 表。

刷新表 ...FOR EXPORT 支持分区 InnoDB 表。

当 InnoDB 收到 FOR EXPORT 通知时，它将某些通常保存在内存或单独磁盘缓冲区外的数据写入磁盘。对于每个表， InnoDB 还生成一个名为 table_name.cfg 的文件，该文件位于数据库目录中。该 .cfg 文件包含重新导入表空间文件所需的元数据。

当 FOR EXPORT 操作完成时， InnoDB 已经将所有脏页刷新到表数据文件中。任何更改缓冲区条目都将在刷新之前合并。在这点上，表被锁定且静止：表在磁盘上处于事务一致状态，您可以复制 .ibd 表空间文件和相应的 .cfg 文件，以获取一致的表快照。

有关将复制的表数据重新导入 MySQL 实例的过程，请参阅第 17.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
```

PREV HOME UP NEXT