mysqladmin flush-hosts能立刻解封被阻塞IP，因其直接清空MySQL的host cache（主机缓存），重置所有IP的错误计数器；但仅治标，病根常在应用配置、DNS或连接池。
立刻能用的解法就是执行 mysqladmin flush-hosts，但别急着敲完就走——它只清缓存，不修病根；而病根往往藏在应用配置、DNS 或连接池里。
为什么 mysqladmin flush-hosts 能立刻解封？
MySQL 内部维护一个 host cache（主机缓存），记录每个 IP 的连接错误次数。一旦某个 IP 的失败计数超过 max_connect_errors（默认常为 10 或 100），就会被加入“拒绝列表”。mysqladmin flush-hosts 的作用就是直接清空这个缓存，让所有被 block 的 IP 立刻恢复尝试连接的资格。
- 它不重启 MySQL，不影响其他连接
- 不需要登录数据库客户端，适合脚本或自动化调用
- 主从架构下，必须对**实际被 block 的那个 MySQL 实例**执行（比如应用连的是从库，就得去从库机器上跑）
- 命令路径不确定时，先用
whereis mysqladmin或find /usr -name mysqladmin 2>/dev/null定位
常见执行失败或无效的几种情况
敲了命令却还是连不上？大概率掉进了这几个坑：
- 权限不足：
mysqladmin需要能认证的用户（如root），且该用户必须有RELOAD权限；如果提示Access denied，不是密码错，就是权限不够 - 连错了实例：你在 A 机器上执行
mysqladmin -h 127.0.0.1 -P 3306，但应用实际连的是 B 机器上的192.168.5.10:3308—— 这个 block 发生在 B，A 上 flush 没用 - 没加参数连远程：默认
mysqladmin尝试本地 socket 连接；要操作远程 MySQL，必须显式指定-h、-P、-u、-p，例如：mysqladmin -h 192.168.5.10 -P 3308 -uroot -p flush-hosts - MySQL 8.0+ performance_schema 关闭时，host cache 行为可能略有差异，但
flush-hosts依然有效
替代方案：在 MySQL 客户端内执行 FLUSH HOSTS
如果你已经能登录到目标 MySQL 实例（比如用 Navicat、mysql -u root -p），那就更简单：
- 直接执行
FLUSH HOSTS;（注意分号） - 无需额外工具，也不依赖
mysqladmin是否可用 - 同样只作用于当前实例，主从需分别执行
- 若提示
ERROR 1227 (42501)，说明当前用户缺少RELOAD权限，换高权限账号再试
真正要盯住的，是哪个 IP 被 block 了？
光解封不够，得知道谁在狂打 MySQL 的门。MySQL 本身不直接暴露“谁被 block”的清单，但你可以这样查：
- MySQL 8.0+：查
performance_schema.host_cache表，过滤HOST列非 NULL 且COUNT_HOST_BLOCKED_ERRORS > 0的行 - 老版本（5.7 及以前）：没有现成视图，只能靠日志反推——打开
log_warnings = 2并检查错误日志，搜索"Host '.*' is blocked" - 快速定位法：看报错信息本身，比如日志里写着
Host '10.20.30.40' is blocked...，那基本就是这个 IP 对应的应用服务器或中间件
最容易被忽略的一点：block 是按 IP + 主机名解析结果双重判断的。如果应用服务器启用了 DNS 反向解析（skip_name_resolve = OFF），而 DNS 不稳，同一个 IP 可能被记成多个 host 名，导致错误计数分散或误判——生产环境建议始终设为 skip_name_resolve = ON。
