你是否遇到过 MySQL 报出 Host is blocked 的错误？先别急着怀疑密码是否正确——这本质上并非单纯的连接失败，而是你的 IP 地址已被 MySQL 主动列入黑名单。此时，即便输入完全正确的密码，数据库也会毫不留情地拒绝访问。要想立刻解除封锁，唯一的办法就是清空 host cache。但执行这一操作有个前提条件：必须连接对实例、拥有足够的权限、参数写完整，否则这条命令只会换来另一行报错信息。
首先厘清一个核心要点：mysqladmin flush-hosts 之所以能立即解除封锁，是因为它清空了 host cache 并重置了错误计数器。然而，许多人在执行时却遇到了 Access denied 或 connect to server failed 的提示——问题往往不在于命令写错，而是连接本身在第一步就没有走通。
为什么 mysqladmin flush-hosts 命令会执行失败？
- 遗漏了
-h和-P参数：默认情况下会走 Unix socket，但许多容器环境或加固后的服务器禁用了 socket，必须强制指定 TCP 连接。正确做法是：mysqladmin -h 127.0.0.1 -P 3306 -u root -p flush-hosts - 远程执行时缺少 IP 和端口信息：例如目标数据库在
192.168.5.10:3308，却只输入mysqladmin -u admin -p flush-hosts，结果连本地 socket 都无法连接，自然失败 - 账号权限不足：执行此操作需要
SUPER或CONNECTION_ADMIN权限，仅有RELOAD是不够的。使用普通应用账号执行必定报错 - MySQL 未启用 host_cache：某些 Docker 镜像在启动时添加了
--skip-host-cache参数，此时执行flush-hosts并不会产生实际效果
在 MySQL 客户端中执行 FLUSH HOSTS 为何没有效果？
能执行成功不代表问题已经解决。这条命令只作用于当前连接的实例，但你可能连错了目标——这才是最常见的问题根源。
- 主从架构下的陷阱：应用实际连接的是从库，但你却在主库上执行了
FLUSH HOSTS。结果从库的 host cache 依然处于 blocked 状态，解封自然无法生效 - 中间件路由问题：如果使用了 ProxySQL、ShardingSphere 这类中间件，流量会被分发到某一台从库，你必须 SSH 登录到该机器，在其 MySQL CLI 中执行才能生效
- 执行后重试仍然失败？ 检查应用是否使用了连接池，旧连接可能仍缓存在池中；另外 DNS 缓存也可能未刷新，尤其是连接字符串使用域名而非 IP 时
- 遇到报错
ERROR 1227 (42501)：说明当前用户缺少RELOAD权限，切换为 root 或 DBA 账号再试
max_connect_errors 参数设置多少才合理？
这个参数设置得过大，会削弱误防护能力；设置得过小，又容易误伤正常业务。关键在于根据部署场景和错误来源的可控性来决定。
- 云数据库的默认值：例如阿里云 RDS 通常默认为 10，测试环境下输错三次密码就可能封禁 IP，非常敏感。内部私有云可以放宽到 200～500 之间
- 临时生效与永久生效的区别：
SET GLOBAL max_connect_errors = 500只对当前会话有效，重启 MySQL 后就会恢复原值。要永久生效，必须写入配置文件[mysqld]段并重启服务 - 公网暴露的实例不建议调高：更稳妥的做法是通过监控提前发现异常连接（例如某个 IP 的错误计数在 1 分钟内飙升到 80），而不是等它爆掉后才去调整参数
- 不要混淆两个参数：
max_connect_errors管理的是“失败次数”，而connect_timeout管理的是“单次握手的超时秒数”。调大后者对解决 block 问题完全没有帮助
说到底，解封操作本身并不复杂，真正棘手的是那个反复触发错误的根源——可能是配置文件中写错的密码、连接池泄漏导致的高频建连、DNS 解析延迟引起的认证超时，或者防火墙静默丢包。解封只是按下了暂停键，如果不查看日志、不监控 performance_schema.host_cache、不验证应用的连接逻辑，几分钟后大概率又会弹出同样的报错信息。所以，不要只学会如何解封，更要掌握如何追根溯源，从根本上解决问题。
