MySQL :: MySQL 9.0 参考手册 :: 15.7.8.3 FLUSH 语句

版本 9.0

8.4 当前
8.0
5.7

8.0 日语

MySQL 9.0 参考手册 / ... / FLUSH 语句

15.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
  | 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
}

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

注意

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

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

注意

FLUSH LOGS、FLUSH BINARY LOGS、FLUSH TABLES WITH READ LOCK（无论是否包含表列表）和 FLUSH TABLES tbl_name ... FOR EXPORT 在任何情况下都不会写入二进制日志，因为如果复制到副本中，它们会导致问题。

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

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

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

RESET 语句类似于 FLUSH。请参阅第 15.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 权限。
此操作对用于常规查询日志的表没有影响（请参阅第 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 或 FLUSH_PRIVILEGES 权限。
如果在服务器启动时指定了 --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 释放缓存的内存，否则缓存的内存使用量会增加。
清除 caching_sha2_password 身份验证插件使用的内存缓存。请参阅 SHA-2 可插拔身份验证的缓存操作。
FLUSH RELAY LOGS [FOR CHANNEL channel]
关闭并重新打开服务器正在写入的任何中继日志文件。如果启用了中继日志记录，中继日志文件的序列号将相对于前一个文件递增 1。
此操作需要 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.6 节，“如何报告错误或问题”。
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 刷新表，并根据使用的变体获取锁。在 FLUSH 语句中使用的任何 TABLES 变体必须是使用的唯一选项。 FLUSH TABLE 是 FLUSH TABLES 的同义词。

注意

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

FLUSH TABLES
关闭所有打开的表，强制使用中的所有表关闭，并刷新已准备好的语句缓存。
此操作需要 FLUSH_TABLES 或 RELOAD 权限。
有关预备语句缓存的信息，请参见第 10.10.3 节，“预备语句和存储程序的缓存”。
当存在活动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 不会阻止服务器将行插入日志表（请参见第 7.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. 此操作将会话置于 lock-tables 模式，以便在FOR EXPORT 操作完成时不会释放之前获取的元数据锁。
此操作仅适用于现有的基本（非TEMPORARY）表。如果一个名称引用了一个基本表，则使用该表。如果它引用了一个TEMPORARY 表，则忽略它。如果一个名称应用于视图，则会发生ER_WRONG_OBJECT 错误。否则，会发生ER_NO_SUCH_TABLE 错误。
InnoDB 支持具有自己的.ibd 文件文件（即使用启用了innodb_file_per_table 设置创建的表）的表的FOR EXPORT。InnoDB 确保在FOR EXPORT 操作通知时，任何更改都已刷新到磁盘。这允许在FOR EXPORT 操作生效时创建表内容的二进制副本，因为.ibd 文件是事务一致的，可以在服务器运行时复制。FOR EXPORT 不适用于InnoDB 系统表空间文件，也不适用于具有FULLTEXT 索引的InnoDB 表。
FLUSH TABLES ...FOR EXPORT 支持分区的InnoDB 表。
在FOR EXPORT 通知后，InnoDB 会将某些通常保存在内存中或在表空间文件之外的单独磁盘缓冲区中的数据写入磁盘。对于每个表，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
```