MySQL 8.0 中 FLUSH TABLES 必须通过全局 RELOAD 权限实现，不支持库表粒度授权；该权限控制所有 FLUSH 类操作，授予时必须使用 ON .，且属高危管理权限，需严格限制 IP 和账号专用。
MySQL 8.0 中无法按表或库粒度授予 FLUSH TABLES 类操作权限 —— 它必须通过全局 RELOAD 权限实现，且该权限只能授予整个实例级别。
为什么 FLUSH TABLES 操作需要 RELOAD 权限
MySQL 把所有 FLUSH 类语句（如 FLUSH LOGS、FLUSH PRIVILEGES、FLUSH TABLES WITH READ LOCK）统一归到 RELOAD 动态权限下。这不是可拆分的细粒度权限，也不支持 ON db.table 语法。一旦缺少它，执行就会报错：
ERROR 1227 (42000): Access denied; you need (at least one of) the RELOAD privilege(s) for this operation
常见触发场景包括：主从搭建时执行 FLUSH TABLES WITH READ LOCK、DBA 手动轮转二进制日志、或某些备份工具调用 FLUSH LOGS。
如何正确授予 RELOAD 权限
必须使用全局作用域（ON *.*），且不能与其他数据库级权限混写在一条 GRANT 语句里 —— 否则会静默失败或权限不生效：
CREATE USER 'backup'@'192.168.253.%' IDENTIFIED BY 'pwd123';GRANT RELOAD ON *.* TO 'backup'@'192.168.253.%';-
GRANT SELECT ON myapp.* TO 'backup'@'192.168.253.%';（读取数据权限可单独加） -
FLUSH PRIVILEGES;（MySQL 8.0 虽多数情况自动刷新，但授予权限后仍建议显式执行）
注意：RELOAD 是高危管理权限，不可与普通应用账号共用；生产环境务必限制 @'host' 的 IP 段，避免泛授权如 @'%'。
RELOAD 权限实际能做什么、不能做什么
它只控制 FLUSH 相关语句，和“重启服务”“修改配置文件”“停库”完全无关：
- ✅ 允许：
FLUSH LOGS、FLUSH TABLES、FLUSH TABLES WITH READ LOCK、FLUSH PRIVILEGES - ❌ 不允许：
SHUTDOWN（需SHUTDOWN权限）、SET GLOBAL（需SYSTEM_VARIABLES_ADMIN）、KILL（需CONNECTION_ADMIN） - ⚠️ 特别注意：
FLUSH TABLES WITH READ LOCK在主从复制中常被误用 —— 它会阻塞所有写入，且在 MySQL 8.0 中若启用了并行复制或 GTID，可能引发从库延迟甚至中断；应优先考虑BACKUP_LOCK（需BACKUP_ADMIN）替代
权限生效后仍报错？排查这三点
即使 GRANT RELOAD ON *.* 已执行，仍可能因以下原因失败：
- 用户连接时使用的 host 不匹配（比如你授的是
'backup'@'192.168.253.%'，但客户端连的是localhost，而localhost在 MySQL 中默认走 socket，不走 TCP，需额外授'backup'@'localhost'） - 账户被
ACCOUNT LOCK锁定（检查SELECT user, host, account_locked FROM mysql.user） - 用户认证插件不兼容（MySQL 8.0 默认用
caching_sha2_password，旧客户端可能握手失败；可用ALTER USER ... IDENTIFIED WITH mysql_native_password BY ...临时降级）
真正麻烦的不是授不授权，而是搞清谁在什么上下文里调用 FLUSH —— 很多自动化脚本或中间件（如某些备份工具、Orchestrator）静默依赖它，但不会告诉你缺哪个权限。先抓 general_log 或看错误日志里的完整 SQL，再对号入座。
