1129错误是mysql因同一ip连续连接失败达max_connect_errors默认阈值（10次）而主动拉黑该ip；执行mysqladmin flush-hosts可清空内存中主机错误计数表，重置失败记录，立即解封。
1129 错误不是数据库挂了，而是 mysql 主动把你的 ip 拉黑了——它记住了你连续失败的连接尝试，达到 max_connect_errors 限制（默认 10 次）就直接拒绝后续所有请求。
为什么 mysqladmin flush-hosts 能立刻解封
MySQL 内部维护一个内存中的主机错误计数表（host cache），flush-hosts 命令会清空这张表，重置所有 IP 的错误计数。它不重启服务、不改配置、不查日志，只做一件事：让 MySQL “忘记”刚才那些失败记录。
- 该命令必须在 MySQL 服务器本机执行，或能直连 MySQL 管理端口（如 3306）的机器上运行
- 如果 MySQL 启用了 skip-name-resolve，
-h参数必须指定为 IP（如127.0.0.1），不能写localhost或主机名 - 密码参数格式敏感：
-proot是合法的，-p root（带空格）会报错，提示你输入密码但实际已传入空密码 - 主从架构下，要分别对主库和从库执行；否则只刷主库，从库仍拦你
mysqladmin 执行失败的常见卡点
命令看似简单，但实际常因权限、路径、网络细节失败：
-
command not found：说明系统没找到mysqladmin，先用whereis mysqladmin或find /usr -name mysqladmin 2>/dev/null定位；常见路径是/usr/bin/mysqladmin或/usr/local/mysql/bin/mysqladmin - 报错
Access denied for user 'root'@'localhost'：说明账号无RELOAD权限，需先用 MySQL 登录后执行GRANT RELOAD ON *.* TO 'root'@'localhost'; FLUSH PRIVILEGES; - 报错
Can't connect to local MySQL server：检查 MySQL 是否真在运行（systemctl status mysql），以及 socket 文件路径是否匹配（可用mysqladmin --socket=/var/run/mysqld/mysqld.sock -u root -p flush-hosts显式指定） - 远程执行时加了
-h却仍连不上：确认目标 MySQL 的bind_address允许该 IP 连接，且防火墙放行对应端口
比 flush-hosts 更容易被忽略的底层原因
很多用户刷完缓存立刻连上了，就以为问题终结——但一小时后又 1129，说明根本原因还在：
- Navicat 测试连接时频繁点“测试”，每次失败都算一次错误计数；建议关掉自动重连、禁用“连接时验证 SSL”等非必要选项
- 公司内网 WiFi 或代理网关做了 NAT，多个终端共用一个出口 IP，A 用户输错密码 8 次 + B 用户输错 3 次 → 同一 IP 达到 11 次被封
- 应用服务部署在容器或云主机里，IP 经过多层转发，MySQL 日志里看到的
host_name可能是负载均衡器或 NAT 网关地址，不是真实客户端 IP -
max_connect_errors改大了（比如设成 1000）却不查日志，等于纵容问题持续发生；真正该看的是mysqld错误日志里紧挨着 1129 出现的前几条连接失败原因（密码错？超时？SSL 不匹配？）
最麻烦的情况不是命令不会敲，而是你刷完了 hosts，Navicat 还连不上——这时候得打开 MySQL 错误日志，搜 connect 和那个被封的 IP，看最后一句失败到底卡在哪。安全机制只是结果，连接链路上任何一环断开，都会喂饱这个计数器。
