有效执行需显式指定连接参数：mysqladmin -h 127.0.0.1 -P 3306 -u root -p flush-hosts，强制TCP连接避免socket权限问题；远程则替换IP、端口、用户名，并确保账号具SUPER或CONNECTION_ADMIN权限。
mysqladmin flush-hosts 命令怎么写才有效
直接执行 mysqladmin flush-hosts 很可能报错“Access denied”，因为该命令需要有 SUPER 或 CONNECTION_ADMIN 权限的账号，且必须能连上 MySQL 的管理端口（默认 3306）。常见失效场景包括：密码错误、用户无权限、目标不是主库、端口或 host 写错。
正确写法要显式指定连接参数：
-
mysqladmin -h 127.0.0.1 -P 3306 -u root -p flush-hosts—— 本地连接，-h 127.0.0.1强制走 TCP，避免 Unix socket 权限干扰 -
mysqladmin -h 192.168.1.100 -P 3307 -u admin -p flush-hosts—— 远程主库，注意替换 IP、端口、用户名 - 若用 SSL 连接，需加
--ssl-mode=REQUIRED参数，否则可能被拒绝
执行后不输出任何内容即为成功；如果提示 mysqladmin: connect to server at 'xxx' failed，说明连都连不上，得先解决基础连接问题（比如检查 mysqld 是否运行、防火墙、bind-address 配置）。
在 MySQL 客户端里执行 flush hosts 为什么有时没用
在已登录的 MySQL CLI 中执行 flush hosts; 确实等价于 mysqladmin flush-hosts，但它只对当前连接的实例生效。容易踩的坑是：
- 主从架构下，应用实际连的是从库（比如读写分离中间件路由），但你只在主库上执行了
flush hosts;—— 从库的 host cache 仍是 blocked 状态 - MySQL 5.7+ 默认启用 host cache，但某些容器化部署（如 Docker MySQL 官方镜像）启动时加了
--skip-host-cache，此时flush hosts;实际无效果，因为 cache 根本没开 - 执行后立刻重试仍失败？可能是应用连接池缓存了旧连接，或 DNS 缓存未刷新（尤其用域名而非 IP 连接时）
max_connect_errors 设成多大才算合理
默认值在 MySQL 5.7 是 100，但很多发行版或云数据库（如阿里云 RDS）设为 10——这就是为什么测试环境改个错密码，连三次就封 IP。调高它不是万能解药：
-
set global max_connect_errors = 1000;立即生效，但重启 MySQL 后恢复默认，需写入配置文件才永久 - 值设太大（比如 10000）会削弱暴力破解防护能力，尤其暴露在公网的实例
- 更稳妥的做法是结合业务行为定值：内部测试网可设为 500；生产核心库建议保持 100，靠监控 + 自动告警提前干预
- 配置文件中加
max_connect_errors = 200到[mysqld]段，然后systemctl restart mysqld
为什么 flush-hosts 后一分钟又报错
这往往不是命令没用，而是错误根源还在持续发生。典型情况有：
- 应用代码里数据库密码写错，每次请求都触发一次失败连接，错误计数器秒回顶
- 连接池配置异常，比如
minIdle=10但连接串错误，启动时就狂建失败连接 - 网络设备（如 SLB、NAT 网关）存在连接中断，导致 TCP 握手完成但认证阶段丢包，MySQL 仍记为 error
- MySQL 5.5 及更老版本不支持动态关闭 host cache，只能加
skip-host-cache并重启，否则只要错误不断，就会反复触发 blocking
真正要止住循环，得先查 show global status like 'Aborted_connects'; 看错误是否还在涨，再顺藤摸瓜定位源头——flush-hosts 只是清计数器，不是修水管。
