connection_control插件不能完全防暴力破解，但能通过延迟响应和连接拒绝提高攻击成本；需启用插件并配置failed_connections_threshold、min_connection_delay等参数才生效。
connection_control 插件到底能不能防暴力破解？
不能完全防，但能显著提高攻击成本——它不阻止首次失败登录，而是对连续失败的客户端实施延迟响应和连接拒绝。关键作用是让自动化脚本“跑不动”，而不是替代密码强度、防火墙或账号锁定策略。
怎么确认并启用 connection_control 插件？
MySQL 5.7.17+ 和 8.0 默认带这个插件，但默认未启用。先检查是否已安装：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'connection%';
如果返回 PLUGIN_STATUS 是 DISABLED 或空，就需手动安装：
- 执行
INSTALL PLUGIN connection_control SONAME 'connection_control.so';（Linux）或'connection_control.dll'（Windows） - 确保
plugin_dir配置正确，可通过SHOW VARIABLES LIKE 'plugin_dir';查看路径 - 插件加载失败常见原因是文件权限不对或 SELinux 拦截，可临时用
setenforce 0排查（生产环境勿长期关闭）
必须配置的三个核心参数
仅启用插件没用，必须设置以下参数才生效（写入 my.cnf 并重启，或运行时 SET GLOBAL，但后者在重启后丢失）：
-
connection_control_failed_connections_threshold = 3：连续失败多少次触发限制（设太低易误伤正常用户） -
connection_control_min_connection_delay = 1000：首次触发后，每次连接强制延迟毫秒数（单位是毫秒，不是秒） -
connection_control_max_connection_delay = 2147483647：最大延迟上限（建议保持默认，避免锁死自己）
注意：min_connection_delay 不是“第 4 次登录才延迟”，而是从第 threshold + 1 次开始，每次连接都加固定延迟。延迟只作用于该客户端 IP，不影响其他来源。
怎么验证它真的在起作用？
别只看日志，要实测：
- 用错误密码连 3 次：
mysql -u test -ptestpass -h127.0.0.1 -P3306（假设账号不存在或密码错） - 第 4 次开始，会明显感觉到响应变慢（延迟约 1 秒），
time命令可测出耗时突增 - 查状态：
SELECT * FROM performance_schema.connection_control_failed_login_attempts;，能看到各客户端 IP 的失败计数 - 错误日志里不会记录“被限流”，只会记常规
Access denied，所以不能靠 error log 判断是否生效
真正容易被忽略的是：这个插件只统计“认证失败”，不区分用户名是否存在；且对 Unix socket 连接默认不生效（除非显式配置 skip-networking=OFF 并监听本地 TCP）。
