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、x64还是arm64）。 - 必须同时加载两个插件：主插件
connection_control和辅助的信息记录插件connection_control_failed_login_attempts，缺一不可。 - 临时加载可以使用命令：
INSTALL PLUGIN connection_control SONAME 'connection_control.so';，但这种方式在MySQL服务重启后会失效。 - 要永久生效，需要在配置文件
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次失败：系统计算的基础延迟是1000毫秒，但如果
min_connection_delay设为了60000，那么实际延迟会被提升到60000毫秒（1分钟）。 - 第5次失败：按规则未调整前应为2000毫秒，但依然会被
min_connection_delay截断为60000毫秒（只要这个值没超过max_connection_delay的上限）。 - 只有当
min_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 命令，或者在前端部署防火墙规则。最后必须提醒一点：延迟参数一旦设置得过高，运维人员自己在管理时也可能被意外卡住——这个潜在影响，恰恰是最容易被忽略的。
