FLUSH HOSTS执行失败因权限不足，需换root或DBA账号执行；若仍不可用，可临时设max_connect_errors为99再设回100触发重置，但根本解法是排查应用配置、连接池SQL错误及网络中断等持续诱因。
FLUSH HOSTS 执行失败：权限不足怎么办
直接在 MySQL 客户端里敲 FLUSH HOSTS; 报错 ERROR 1227 (42501): Access denied; you need (at least one of) the RELOAD privilege(s)，说明当前账号没权限。应用账号默认不带 RELOAD，这是设计使然，不是配置漏了。
可行路径只有三条：
- 换用
root或 DBA 账号登录 MySQL 后再执行FLUSH HOSTS; - 用
mysqladmin -uroot -p flush-hosts（注意密码含特殊字符时建议交互式输入，避免 shell 解析出错） - Docker 环境下走
docker exec mysql-db mysqladmin -uroot -p'xxx' flush-hosts，别忘了检查容器名和密码是否匹配
刚 flush 完又 blocked：根本问题还在持续发生
这不是命令失效，是错误连接行为没停——只要失败还在发生，host cache 里的计数就立刻重累加。
典型源头包括：
- 应用配置写死了错密码或错用户名，每次重启/重连都触发一次失败
- 连接池（如 HikariCP、Druid）开了
connection-test-query，但 SQL 语法错误或表不存在，建连后立即报错 → 计入错误次数 - 防火墙、SLB 或 Nginx TCP proxy 主动断开空闲连接，MySQL 收不到
FIN包，判定为异常中断 -
max_connect_errors被设成 10 这种极低值，而 DNS 解析慢或网络抖动本就存在
查不到谁被 block 了？performance_schema 是唯一可靠入口
SHOW VARIABLES LIKE 'max_connect_errors' 只告诉你阈值，不告诉你哪个 IP 超了。MySQL 8.0+ 的真实状态全在 performance_schema.host_cache 里，老版本只能靠猜或翻错误日志。
执行这句就能看到具体 IP 和当前错误计数：
SELECT HOST, IP, SUM_CONNECT_ERRORS, COUNT_HOST_BLOCKED_ERRORS FROM performance_schema.host_cache WHERE SUM_CONNECT_ERRORS > 0;
注意：需要 PROCESS 权限；如果返回空，说明不是 host block，得去查别的错误类型（比如 max_connections 耗尽）。
临时绕过但别依赖：SET GLOBAL max_connect_errors 触发重置
没高权限又急需恢复？可以试这个“擦边球”操作：
- 先执行
SET GLOBAL max_connect_errors = 99; - 再立刻执行
SET GLOBAL max_connect_errors = 100;
MySQL 内部会把当前连接对应 host 的错误计数清零，但前提是该 host 的连接还没断开（即你正用它连着）。它不保证 100% 成功，也不解决任何底层问题，只适合应急。生产环境调大 max_connect_errors 到 ≥200 后，必须同步排查连接池配置、DNS 缓存、SSL 参数错配这些真正咬人的点。
