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

版本 8.4

8.0 日本语

MySQL 8.4 参考手册 / ... / 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.8 节，“存储程序限制”。

默认情况下，服务器将 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。有关使用 RESET 进行复制的信息，请参阅第 15.7.8.6 节“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. 此操作将会话置于锁定表模式，以便在FOR EXPORT 操作完成后不会释放之前获取的元数据锁。
此操作只适用于现有的基本（非TEMPORARY）表。如果名称引用基本表，则使用该表。如果引用TEMPORARY 表，则忽略该表。如果名称应用于视图，则会发生ER_WRONG_OBJECT 错误。否则，会发生ER_NO_SUCH_TABLE 错误。
InnoDB 支持具有自己的.ibd 文件的表的FOR EXPORT（即使用启用了innodb_file_per_table 设置创建的表）。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
```