connection control插件仅通过延迟响应防暴力破解，不锁定账号；设threshold=3却无效，是因为min_connection_delay默认为0毫秒，必须显式设为非零值（如60000）才生效。
connection_control 插件不锁定账号，只加延迟——设了阈值但没配 connection_control_min_connection_delay，就等于没开功能。
为什么设了 threshold=3 却没效果？
因为 connection_control_failed_connections_threshold 只是“计数开关”，不是“拦截开关”。它只决定从第几次失败开始启用延迟逻辑，真正让客户端卡住的是 connection_control_min_connection_delay。
- 该变量默认为 0，意味着即使触发阈值，延迟也是 0 毫秒 → 客户端完全无感
- 必须显式设为非零值，比如
SET GLOBAL connection_control_min_connection_delay = 60000;（60 秒） - 这个值单位是毫秒，写
60是 60 毫秒，基本看不出；写60000才是 1 分钟 - 仅对认证失败（
ERROR 1045 (28000)）计数，用户不存在、SSL 错误、网络超时都不算
插件加载失败的典型表现和修复
执行 SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'connection_control'; 返回空或 DISABLED，说明插件根本没起来。
- Linux 下检查文件是否存在：
/usr/lib/mysql/plugin/connection_control.so（路径依安装方式而异） - Windows 下对应
connection_control.dll，注意架构匹配（x86 vs x64 vs arm64） - 必须同时加载两个插件：
connection_control和connection_control_failed_login_attempts，缺一不可 - 临时加载命令：
INSTALL PLUGIN connection_control SONAME 'connection_control.so';，但重启后失效 - 永久生效：在
my.cnf的[mysqld]段加两行：plugin_load_add = connection_control.soplugin_load_add = connection_control_failed_login_attempts.so
延迟怎么算？不是固定值
connection_control 的延迟是递增的，且受 min_connection_delay 和 max_connection_delay 截断。假设 failed_connections_threshold=3：
- 第 1–3 次失败：无延迟
- 第 4 次失败：基础延迟 1000ms，但被
min_connection_delay截断为实际值（如设为 60000，则就是 60000ms） - 第 5 次失败：未调整前应为 2000ms，仍被截断为 60000ms（因未超
max_connection_delay） - 只有当
min_connection_delaymax_connection_delay 时，才能看到阶梯式增长 - 一次成功登录会清空该用户的失败计数，下次再输错又从头开始
怎么确认它真在起作用？
别信客户端报错——所有失败都返回 ERROR 1045 (28000)，无法区分是密码错还是被延迟卡住。
- 查实时状态：
SHOW STATUS LIKE 'Connection_control_delayed_connections';，返回值 > 0 说明插件已介入 - 查历史记录（需开启
performance_schema）：SELECT * FROM performance_schema.connection_control_history; - 错误日志（
log_error指定路径）里不会出现 connection_control 相关提示，grep 不到“已延迟”“已拦截”之类字段 - 测试时避免用
127.0.0.1或localhost反复试，容易把自己卡住且难排查
connection_control 的核心意图是拖慢暴力破解节奏，不是替代账号封禁。如果你需要“彻底拒绝连接”，得配合 max_connect_errors + FLUSH HOSTS，或前置防火墙规则。延迟参数一旦设高，运维连自己都可能被卡住——这点最容易被忽略。
