立刻恢复连接只有执行FLUSH HOSTS或用高权限账号重置IP错误计数两种办法；FLUSH HOSTS清空host_cache释放所有被封IP，需RELOAD权限，连不上时可用mysqladmin -u root -p flush-hosts，主从架构须各节点分别执行。
立刻恢复连接只有两个办法：执行 FLUSH HOSTS，或用高权限账号重置对应 IP 的错误计数。等、重启客户端、改 connect_timeout 都没用。
执行 FLUSH HOSTS 是最直接的解法，但要注意权限和副作用
这个命令会清空 MySQL 内部的 host_cache 表，所有被 block 的 IP 都会被释放——包括你没意识到也在失败的其他 IP。
- 需要
RELOAD权限，普通应用账号基本没有，得用root或 DBA 账号登录后执行FLUSH HOSTS; - 如果无法进 MySQL（比如连都连不上），可用
mysqladmin：/usr/bin/mysqladmin -h 127.0.0.1 -P 3306 -u root -p flush-hosts - 主从架构下，必须在主库和所有从库上分别执行；只刷主库，从库仍会拒绝该 IP
- 执行完不等于问题消失——它只是擦掉计数，错误源头还在继续累加
max_connect_errors 调大能延缓报错，但掩盖真实问题
默认值是 100，意味着同一 IP 连续失败 100 次就会被拉黑。调到 300 或 500 可争取排查时间，但不能替代根因修复。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 临时生效：
SET GLOBAL max_connect_errors = 300;（需 SUPER 权限） - 永久生效：在
my.cnf的[mysqld]段落下加一行max_connect_errors = 300，然后重启 MySQL - 别设成 999999——这等于关掉防护，给暴力破解留了门
- MySQL 8.0+ 中该参数和
host_cache_size耦合更紧，盲目调大会增加内存开销
查不到谁被 block？MySQL 8.0+ 必须查 performance_schema.host_cache
老版本只能靠猜 IP 或翻错误日志，MySQL 8.0 起把实时状态放进了性能库，但默认关闭且需要 PROCESS 权限。
- 先确认是否启用：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema'; - 查具体 IP 的失败次数：
SELECT HOST, SUM_CONNECT_ERRORS, COUNT_HOST_BLOCKED_ERRORED FROM performance_schema.host_cache WHERE HOST = '10.45.236.235'; - 注意：该表字段名在不同小版本有差异，
SUM_CONNECT_ERRORS才是累计失败数，不是COUNT_STAR - 没权限时，
SHOW VARIABLES LIKE 'max_connect_errors';只告诉你阈值，不告诉你谁超了
真正反复触发的，八成是连接池或配置写错了
很多团队刷完 FLUSH HOSTS 十分钟又爆，根本不在 MySQL 侧，而在应用端。
- Spring Boot + HikariCP 常见：URL 里写了错密码、
allowPublicKeyRetrieval=true缺失导致 SSL 握手失败、JDBC 参数拼错（如useSSL写成useSsl） - 测试环境高频启停服务，连接池未 close 就 exit，MySQL 把残留半开连接记为异常中断
- DNS 解析慢或代理不稳定，TCP 连上了但握手卡住，超时后计入
max_connect_errors - 防火墙/SLB 主动断连（如阿里云 SLB 默认 60 秒空闲断连），MySQL 收不到 FIN，视为异常
最常被忽略的一点：block 状态不是按“IP + 端口”维度，而是按“解析出的 hostname”来的。如果 MySQL 启用了 skip_name_resolve=OFF（默认），同一个 IP 用不同域名访问（app1.internal / app2.internal），会被算作两个 host，各自独立计数——但日志里只显示 IP，容易误判。
