确认是max_connect_errors触发的封禁：看到“host 'xxx' is blocked because of many connection errors”错误即可锁定，执行select @@max_connect_errors确认阈值（默认100），再查performance_schema.host_cache表中对应ip的connect_errors字段验证封禁状态。
这是 IP 级封禁，不是连接数超限，也不是权限错——连认证环节都进不去，直接被 MySQL 拒绝握手。
怎么确认是 max_connect_errors 触发的封禁
看到错误信息 Host 'xxx' is blocked because of many connection errors 就基本可以锁定。它和 Too many connections 完全无关，也不出现在 SHOW PROCESSLIST 里。
- 执行
SELECT @@max_connect_errors;—— 默认值是 100，表示同一 Host 连续失败 100 次就拉黑 - 查封禁状态最准的方式是：
SELECT HOST, CONNECT_ERRORS FROM performance_schema.host_cache WHERE HOST = '192.168.1.100';（把 IP 替换为实际客户端地址） - 注意：5.7+ 版本中
connect_errors字段已从mysql.user表移除，查mysql.user会返回空或过时数据 - 如果查
performance_schema.host_cache返回空，大概率是启用了skip_name_resolve = ON，此时 MySQL 直接按 IP 匹配，但表本身可能因配置未启用而为空——得结合错误日志或云厂商控制台看
为什么 FLUSH HOSTS 后立刻又封了
FLUSH HOSTS; 只清空 host_cache 的统计缓存，不解决重试源头。几秒内复现，说明应用还在持续发错请求。
- 检查 JDBC URL 中的
user和password：特别注意密码含@、/、:等字符是否被 URL 编码（比如@必须写成%40） - 如果连的是域名，DNS 解析出多个 IP，其中某些 IP 对应的实例账号/密码不一致，会导致部分请求必错
- Spring Boot 应用若配置了 aggressive 重试（如
spring.datasource.hikari.connection-timeout=1000+ 失败后立即重试），1 秒内打几十次错连接，瞬间达标 - 云数据库（如阿里云 RDS）通常屏蔽
performance_schema查询，此时只能靠错误日志定位失败 IP，或在控制台“安全审计”或“错误日志”模块过滤Access denied记录
临时解封 + 防复发的关键操作
只跑 FLUSH HOSTS; 是无效动作。必须同步做三件事：
- 立刻停掉问题应用或配置，避免继续触发；或临时切到备用 DB 实例
- 调低重试频率：HikariCP 中设
connection-timeout=3000，并关闭自动重试逻辑（如 Spring Boot 的spring.datasource.hikari.initialization-fail-timeout不要设负值） - 改 MySQL 配置加一行：
max_connect_errors = 999（不推荐设 0，等于关防护；999 是兼顾容错与安全的经验值） - 注意：该变量是全局的，无法 per-IP 或 per-user 设置；想豁免某 IP，只能靠 DNS 绕行或代理层拦截错误请求
真正难处理的不是封禁本身，而是错误请求藏在定时任务、离线脚本或监控探针里——它们不走主应用链路，容易被忽略。建议在数据库前置加一层连接日志代理（如 ProxySQL），或开启 MySQL 的 general_log（仅临时），才能抓到真实来源。
