MySQL连接控制插件需手动安装启用，否则配置无效；默认绕过localhost等连接，阈值不持久化且按用户+主机独立计数，需结合防火墙与最小权限原则综合防护。
mysql连接控制插件没启用，登录失败次数不记账
插件不启用，connection_control 和 connection_control_failed_connections_threshold 这些配置就只是配置文件里的文字。MySQL 启动时不会自动加载它，必须手动安装并开启。
实操建议：
- 先连上 MySQL，执行
INSTALL PLUGIN connection_control SONAME 'connection_control.so';（Linux）或'connection_control.dll'（Windows） - 确认已加载：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'connection_control';，状态得是ACTIVE - 检查变量是否生效：
SHOW VARIABLES LIKE 'connection_control%';，特别注意connection_control_failed_connections_threshold默认是 3，太低容易误锁；建议调成 5–10 - 如果报错
Plugin 'connection_control' is disabled，说明 mysqld 启动时加了--plugin-load-add=connection_control=OFF或配置里写了disabled_storage_engines类似干扰项，得清理
设置了阈值但没触发延迟，可能是用户白名单在起作用
connection_control 插件默认把 localhost、127.0.0.1 以及所有 skip-grant-tables 模式下的连接都绕过控制——这很合理，但也常被忽略。
实操建议：
- 检查当前连接来源：
SELECT USER(), CURRENT_USER();，如果返回的是'root'@'localhost'，那不管输错多少次都不会被限流 - 生产环境远程管理账号务必用具体 IP 或域名创建，比如
CREATE USER 'admin'@'192.168.10.50';，别依赖'root'@'localhost'做日常操作 - 插件对
super_priv用户不强制限流（MySQL 8.0.19+ 可通过connection_control_failed_connections_threshold配合connection_control_min_connection_delay控制，但 root 仍可能豁免），所以别让业务账号拥有SUPER权限
暴力破解没拦住，因为应用层重试太快，插件根本来不及响应
插件的限流逻辑是：连续失败达到阈值后，后续每次连接尝试都会被强制延迟（默认 1000ms）。但如果客户端用短连接 + 快速重试（比如 Python 的 mysql-connector 默认重试 1 次且间隔极短），看起来就像“没生效”。
实操建议：
- 调高基础延迟：
SET GLOBAL connection_control_min_connection_delay = 2000;（单位毫秒），避免被快速重试冲掉效果 - 确认应用是否启用了连接池；如果用了
maxReconnects=3这类参数，实际一次错误会引发多次底层连接尝试，得在中间件或负载均衡层也做频率限制 - 观察日志：
SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%ERROR%';，配合错误日志里的Access denied for user行数，判断是真实攻击还是误配导致的高频失败
连接被锁死却查不到记录，因为 failed_connections 计数只存在内存中
connection_control_failed_connections_threshold 的计数不是持久化到磁盘的，重启 MySQL 就清零。而且它只针对单个用户+主机组合（如 'attacker'@'203.204.205.206'），不同 IP 即使同名用户也不共享计数。
实操建议：
- 不要指望靠查某张表来“看历史失败次数”，这个计数没有对应视图暴露；唯一可观测方式是开慢日志 + 错误日志，过滤
Access denied并按 host 分组统计 - 如果发现某个 IP 突然大量失败，优先在防火墙层封禁，比如
iptables -A INPUT -s 203.204.205.206 -j DROP，比依赖 MySQL 插件更及时 - 插件无法防御密码正确但权限不足的试探（比如知道账号、猜库名/表名），这类行为不会触发
Access denied for user，得靠审计日志（audit_log插件）或代理层识别
真正难防的不是连不上，而是连得上但权限太宽——插件只能卡住“错密码”，卡不住“对密码+错权限设计”。所以账号最小权限原则比任何连接控制都关键。
