MySQL FLUSH 命令：数据库管理员完整参考指南

MySQL的`FLUSH`语句强制服务器重新加载内部缓存、关闭并重新打开日志文件、重置状态计数器，并将内存状态与磁盘结构同步——所有这些操作均无需重启服务器。这使其成为数据库管理员可用的最关键操作命令系列之一。

了解每个变体、其精确范围及副作用，对于生产环境而言不是可选知识。例如，在繁忙的OLTP系统上误用`FLUSH TABLES WITH READ LOCK`，可能导致应用程序范围内的写入停顿长达数分钟。本参考资料涵盖所有重要的`FLUSH`变体，包括MySQL 5.7与8.x之间的行为差异、InnoDB特定影响、复制风险以及权限要求。

为什么FLUSH命令在生产环境中至关重要

MySQL服务器维护着大量内存结构以加速操作：主机连接缓存、授权表缓存、打开的表描述符、查询结果缓存以及存储引擎缓冲池。这些缓存在运行时具有权威性。当管理员进行带外更改时——例如直接使用`INSERT`/`UPDATE`编辑授权表、在操作系统层面轮转日志文件，或移动`.ibd`文件——服务器的内存视图将变得过时。`FLUSH`命令用于消除这种差异。

`FLUSH`不可或缺的关键操作类别：

• 权限传播，无需重启`mysqld`
• 一致的在线备份，使用基于锁的快照
• 日志轮转，与`logrotate`或自定义脚本集成
• 性能基准重置，用于基准测试前
• 主机缓存失效，在网络拓扑变更后
• 存储引擎持久性强制执行，在维护窗口前

所需权限

大多数`FLUSH`变体需要`RELOAD`权限。`FLUSH TABLES WITH READ LOCK`还额外需要`LOCK TABLES`。在MySQL 8.0+中，引入了细粒度动态权限（`FLUSH_OPTIMIZER_COSTS`、`FLUSH_STATUS`、`FLUSH_TABLES`、`FLUSH_USER_RESOURCES`），允许更精细的访问控制，而无需授予宽泛的`RELOAD`权限。在将这些权限分配给应用程序或监控账户时，请始终遵循最小权限原则。

完整参考：MySQL FLUSH命令

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

此命令从`mysql`系统数据库（`mysql.user`、`mysql.db`、`mysql.tables_priv`、`mysql.columns_priv`、`mysql.procs_priv`）重新加载内存中的授权表。服务器在启动时读取这些表并将其缓存。对这些表进行的任何直接DML操作（`INSERT`、`UPDATE`、`DELETE`）都会绕过正常的`GRANT`/`REVOKE`机制，导致缓存在执行`FLUSH PRIVILEGES`之前保持过时状态。

使用时机：

• 使用原始SQL而非`GRANT`/`REVOKE`语句手动编辑授权表后
• 导入包含直接插入`mysql.user`的mysqldump后
• 恢复`mysql`模式的部分备份后

关键细节：当使用`GRANT`、`REVOKE`、`CREATE USER`或`DROP USER`语句时，MySQL会自动重新加载授权表。`FLUSH PRIVILEGES`仅在完全绕过这些语句时才有必要。不必要地运行它无害，但会在授权表缓存上添加短暂的锁。

复制注意事项：`FLUSH PRIVILEGES`默认会写入二进制日志并复制到副本。在跨复制拓扑管理用户时，这通常是所期望的行为。

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

此命令关闭所有当前打开的表文件描述符，并将其从表定义缓存（TDC）中移除。下次访问时，MySQL将从磁盘重新打开表文件。这在进行任何带外文件操作后至关重要。

使用时机：

• 在操作系统层面复制或替换`.frm`、`.ibd`或`.MYD`/`.MYI`文件后
• 在`table_open_cache`值非常大的服务器上释放表缓存内存
• 在InnoDB可传输表空间操作中使用`IMPORT TABLESPACE`之前的前提条件

性能考量：在拥有数千个打开表的服务器上，`FLUSH TABLES`会短暂获取全局锁。在高并发系统上，这可能导致明显的延迟峰值。建议使用特定表的形式（`FLUSH TABLES tbl1, tbl2`）以最小化影响。

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

这是最强大也最具潜在破坏性的`FLUSH`变体之一。它关闭所有打开的表，刷新查询缓存，并获取全局读锁，阻止所有数据库上的任何写操作。该锁持续到发出`UNLOCK TABLES`或会话结束为止。

使用时机：

• 使用`mysqldump –single-transaction`等工具进行物理备份之前（对于仅使用InnoDB的数据库，这是不必要的——见下文）
• 在非InnoDB环境中使用`mysqlpump`或`xtrabackup`之前
• 跨混合存储引擎（InnoDB + MyISAM）创建时间点一致快照

关键陷阱——仅使用InnoDB的数据库：对于专门使用InnoDB表的数据库，几乎永远不需要`FTWRL`。`mysqldump –single-transaction`会打开一个可重复读事务，提供一致的快照而不阻塞写操作。在此场景下使用`FTWRL`会导致不必要的写入停顿。

复制风险：如果在副本上执行`FTWRL`，它会阻塞SQL应用线程，导致在锁持续期间复制延迟不断累积。释放锁后，请始终监控`Seconds_Behind_Master`。

元数据锁交互：在MySQL 5.7+中，`FTWRL`在获取全局锁之前会等待所有活动事务完成。在有长时间运行事务的繁忙服务器上，这种等待可能是无限期的。在执行`FTWRL`之前，使用`SHOW PROCESSLIST`识别阻塞事务。

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL维护一个主机缓存，记录连接尝试历史，包括失败的身份验证计数。当某个主机累计超过`max_connect_errors`次连续失败连接时，MySQL会阻止该主机的所有后续连接，直到缓存条目被清除。

使用时机：

• 当合法客户端主机因超过`max_connect_errors`而被阻止时
• 解决导致重复TCP连接失败的网络问题后
• 更改影响服务器解析客户端主机名方式的DNS记录后

MySQL 8.0替代方案：在MySQL 8.0+中，也可以直接截断主机缓存表：

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

这可以达到相同的效果，并且在自动化脚本中更加透明。

主动配置：与其被动依赖`FLUSH HOSTS`，不如将`max_connect_errors`设置为更高的值（例如`10000`），或将`host_cache_size = 0`设置为在受信任的内部网络上完全禁用主机缓存。

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

将大多数会话和全局状态变量重置为零。这包括`Com_select`、`Handler_read_rows`、`Innodb_buffer_pool_reads`、`Threads_connected`等计数器，以及通过`SHOW STATUS`或`performance_schema`公开的数百个其他计数器。

使用时机：

• 在受控基准测试之前立即执行，以建立干净的测量基准
• 在配置更改后（例如调整`innodb_buffer_pool_size`），以隔离对I/O指标的影响
• 在编写比较前后计数器差值的性能回归测试脚本时

重要限制：`FLUSH STATUS`不会重置所有计数器。`Uptime`、`Uptime_since_flush_status`以及某些InnoDB内部指标等变量不受影响。对于全面监控，请直接使用`performance_schema`表，它提供了`FLUSH STATUS`无法提供的每线程和每事件粒度。

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS`关闭并重新打开所有服务器日志文件。MySQL 5.7.2+引入了单独刷新特定日志类型的能力，这在生产环境中更为可取。

使用时机：

• 作为`logrotate`轮转后脚本的一部分，在旧日志文件被轮转后通知MySQL打开新日志文件
• 强制创建新的二进制日志文件（等同于`FLUSH BINARY LOGS`），这会递增二进制日志序列号
• 在归档旧日志之前，确保所有待处理的写入都已刷新到磁盘

二进制日志详情：`FLUSH BINARY LOGS`创建一个新的二进制日志文件，并向旧文件写入`Rotate_event`。这是为时间点恢复（PITR）归档分段二进制日志的正确方式。可以通过`SHOW MASTER STATUS`（MySQL 5.7）或`SHOW BINARY LOG STATUS`（MySQL 8.4+）确认当前二进制日志文件和位置。

logrotate集成示例：

“`bash

/etc/logrotate.d/mysql

/var/log/mysql/mysql-slow.log {

daily

rotate 7

missingok

compress

postrotate

mysqladmin -u root -p flush-logs

endscript

}

“`

7. FLUSH QUERY CACHE

“`sql

FLUSH QUERY CACHE;

RESET QUERY CACHE;

“`

弃用警告：MySQL查询缓存在MySQL 5.7.20中被弃用，并在MySQL 8.0中被完全移除。如果您运行的是MySQL 8.0或更高版本，此命令不存在。

对于查询缓存仍然活跃的MySQL 5.6/5.7环境：

• `FLUSH QUERY CACHE`对查询缓存内存进行碎片整理，而不删除缓存的结果
• `RESET QUERY CACHE`完全删除所有缓存的查询结果

使用时机（仅限MySQL 5.6/5.7）：

• 在大批量数据修改使大量缓存结果失效后
• 当`Qcache_free_blocks`相对于`Qcache_total_blocks`较高时，表明存在碎片化
• 在禁用查询缓存（`SET GLOBAL query_cache_size = 0`）之前，以干净地释放内存

现代替代方案：在MySQL 8.0+上，使用InnoDB缓冲池预热（`innodb_buffer_pool_dump_at_shutdown`、`innodb_buffer_pool_load_at_startup`）和`performance_schema`进行查询级别分析。

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

重置MySQL内置速率限制跟踪的每用户资源计数器。这些计数器强制执行在`CREATE USER`或`GRANT`语句中定义的限制：

• `MAX_QUERIES_PER_HOUR`
• `MAX_UPDATES_PER_HOUR`
• `MAX_CONNECTIONS_PER_HOUR`
• `MAX_USER_CONNECTIONS`

使用时机：

• 当用户已耗尽其每小时查询配额，需要在计数器在下一个小时边界自然重置之前立即恢复访问时
• 在增加用户资源限制后，希望新限制立即生效时
• 在开发/测试期间，在测试运行之间重置配额

注意：此命令同时重置所有用户的计数器。在`FLUSH`级别没有每用户粒度。如果需要重置单个用户的计数器，唯一的选择是使用`ALTER USER`修改其账户，然后发出`FLUSH USER_RESOURCES`。

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

强制所有存储引擎将其待处理的写入缓冲区刷新到各自的日志文件。对于InnoDB，这意味着将重做日志缓冲区（`innodb_log_buffer_size`）刷新到磁盘上的InnoDB重做日志文件。

使用时机：

• 在对InnoDB数据文件进行冷备份之前，以确保重做日志一致性
• 在存储引擎故障排除期间，排除与缓冲区相关的数据不一致问题
• 作为停止MySQL服务前维护检查清单的一部分

InnoDB持久性背景：InnoDB的`innodb_flush_log_at_trx_commit`设置控制每次事务提交时重做日志的刷新积极程度。`FLUSH ENGINE LOGS`是一个手动覆盖，无论该设置如何都会强制刷新。这在需要保证持久性检查点而不提交事务的场景中非常有用。

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

重新加载由`–des-key-file`服务器启动选项指定的DES加密密钥文件。此密钥文件由`DES_ENCRYPT()`和`DES_DECRYPT()`函数使用。

弃用警告：`DES_ENCRYPT()`和`DES_DECRYPT()`函数在MySQL 5.7.6中被弃用，并在MySQL 8.0中被移除。因此，此命令仅与旧版MySQL 5.6/5.7安装相关。

现代加密替代方案：对于生产加密需求，请使用MySQL原生的静态数据加密（通过`ALTER TABLE … ENCRYPTION='Y'`实现的InnoDB表空间加密）结合MySQL Keyring插件（`keyring_file`、`keyring_okv`、`keyring_aws`）。

FLUSH命令对比表

复制与FLUSH：哪些内容会被复制

并非所有`FLUSH`命令都会复制到副本服务器。在高可用和复制拓扑中，理解这一区别至关重要：

默认复制：

• `FLUSH PRIVILEGES`
• `FLUSH LOGS`（在二进制日志中写入为`Rotate_event`）
• `FLUSH USER_RESOURCES`

不复制（会话本地或明确排除）：

• `FLUSH TABLES WITH READ LOCK` — 从不写入二进制日志
• `FLUSH STATUS` — 仅影响本地服务器的计数器
• `FLUSH HOSTS` — 仅限本地主机缓存
• `FLUSH ENGINE LOGS` — 仅限本地引擎状态

要防止特定`FLUSH`命令在通常情况下被复制，请使用`LOCAL`或`NO_WRITE_TO_BINLOG`修饰符：

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

这在副本上独立管理权限时非常有用（例如，添加不应存在于主库上的监控用户）。

使用mysqladmin自动化FLUSH操作

许多`FLUSH`操作可以从shell触发，无需打开MySQL客户端会话，这在cron作业和维护脚本中非常有用：

“`bash

Flush binary logs

mysqladmin -u root -p flush-logs

Flush privileges

mysqladmin -u root -p flush-privileges

Flush host cache

mysqladmin -u root -p flush-hosts

Flush status counters

mysqladmin -u root -p flush-status

“`

对于生产环境，请将凭据存储在具有`chmod 600`权限的`~/.my.cnf`中，而不是以交互方式传递`-p`，或使用MySQL的`–login-path`机制配合`mysql_config_editor`。

托管环境注意事项

执行`FLUSH`命令的能力在很大程度上取决于托管环境和所授予的数据库访问级别。在VPS托管方案中，您通常拥有对MySQL实例的完整root访问权限，这意味着您可以执行任何`FLUSH`变体、修改`my.cnf`并直接管理日志轮转。这是任何严肃数据库管理工作的最低推荐环境。

在共享虚拟主机上，数据库访问通常限于没有`RELOAD`权限的非特权用户，使大多数`FLUSH`命令不可用。如果您的应用程序需要权限管理、日志轮转控制或备份一致快照，共享环境将是一个硬性障碍。

对于高吞吐量数据库工作负载——特别是涉及频繁`FLUSH ENGINE LOGS`操作或大型InnoDB缓冲池的工作负载——独立服务器提供了使这些操作不具破坏性所需的I/O吞吐量和内存带宽。在拥有256 GB缓冲池数据的服务器上执行`FLUSH TABLES WITH READ LOCK`，与在具有快速NVMe存储和专用I/O通道的服务器上相比，耗时明显更长。

如果您在Web控制面板旁边管理MySQL实例，带cPanel的VPS提供了一个托管环境，其中某些`FLUSH`操作（特别是日志轮转和权限重载）由控制面板的数据库管理层自动处理，减少了手动干预的需求。

对于需要完整控制面板生态系统的数据库支持应用程序，查看可用的VPS控制面板将有助于确定哪个面板最能与您的MySQL管理工作流集成。

关键要点检查清单

在生产环境中执行任何`FLUSH`命令之前，请使用此决策矩阵：

• 执行`FLUSH TABLES WITH READ LOCK`之前：确认没有长时间运行的事务处于活动状态（`SHOW PROCESSLIST`）。验证您的数据库是否仅使用InnoDB——如果是，请改用`–single-transaction`。
• 执行`FLUSH PRIVILEGES`之前：确认您正在对授权表使用原始DML。如果使用了`GRANT`/`REVOKE`，此命令是多余的。
• 执行`FLUSH LOGS`之前：确保您的日志轮转脚本在通知MySQL重新打开日志文件之前已经移动/重命名了旧日志文件。
• 执行`FLUSH HOSTS`之前：首先找出连接失败的根本原因。在不修复底层问题的情况下刷新主机缓存将导致该主机再次被封锁。
• 在MySQL 8.0+上：从脚本中删除任何`FLUSH QUERY CACHE`或`FLUSH DES_KEY_FILE`调用——这些命令不存在，将导致错误。
• 在复制拓扑中：当操作不应传播到副本时，使用`FLUSH LOCAL`或`FLUSH NO_WRITE_TO_BINLOG`。
• 对于自动化：在脚本中使用`mysqladmin flush-*`命令，而不是打开完整的MySQL客户端会话。
• 权限审计：对于监控和备份账户，优先使用MySQL 8.0动态权限（`FLUSH_STATUS`、`FLUSH_TABLES`等），而非宽泛的`RELOAD`权限。

常见问题

每次执行GRANT或REVOKE语句后都需要运行FLUSH PRIVILEGES吗？

不需要。`GRANT`、`REVOKE`、`CREATE USER`和`DROP USER`会自动重新加载内存中的授权表。`FLUSH PRIVILEGES`仅在直接对`mysql`系统表进行DML修改后才有必要（例如`UPDATE mysql.user SET …`）。

FLUSH TABLES WITH READ LOCK会导致应用程序停机吗？

是的。它获取全局写锁，阻止服务器上所有数据库的`INSERT`、`UPDATE`、`DELETE`和DDL操作。在繁忙的OLTP系统上，即使几秒钟的`FTWRL`也可能耗尽连接池并导致级联应用程序错误。对于仅使用InnoDB的数据库，请使用`mysqldump –single-transaction`来完全避免这种情况。

FLUSH STATUS与重启MySQL服务器在基准测试目的上是否相同？

不相同。`FLUSH STATUS`重置大多数状态计数器，但不会清除InnoDB缓冲池、重置连接状态或影响`performance_schema`累积的统计数据。对于真正的全新基准测试，结合缓冲池清除的服务器重启更为准确，尽管在生产环境中不切实际。

为什么FLUSH HOSTS在某些MySQL 8.0文档中不作为独立命令存在？

`FLUSH HOSTS`在MySQL 8.0中仍然有效，但首选方法是`TRUNCATE TABLE performance_schema.host_cache`，它更加明确，并且如果用户对`performance_schema`具有`DELETE`权限，则无需`RELOAD`权限即可执行。两者都能达到相同的效果。

在InnoDB高写入负载期间执行FLUSH ENGINE LOGS会发生什么？

它会强制将InnoDB日志缓冲区同步刷新到磁盘，如果重做日志文件位于慢速存储上，可能会导致短暂的写入停顿。在NVMe支持的服务器上，影响通常在毫秒以下。在旋转磁盘或负载较重的SAN存储上，可能会导致明显的延迟峰值。尽可能在低流量窗口期间安排此操作。