mysql如何实现自动锁定多次密码输错的账号_配置connection_control延迟

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.so
plugin_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 命令，或者在前端部署防火墙规则。最后必须提醒一点：延迟参数一旦设置得过高，运维人员自己在管理时也可能被意外卡住——这个潜在影响，恰恰是最容易被忽略的。