wait_timeout和interactive_timeout必须设为相同值，否则命令行连接仍保持默认8小时，易被复用绕过限制；生产环境建议统一设为300～600秒，并写入配置文件重启生效。
wait_timeout 和 interactive_timeout 必须设为相同值
MySQL 不会自动让两个超时参数同步生效。如果只改 wait_timeout 而漏掉 interactive_timeout，命令行登录的连接仍会保持 8 小时（默认 28800 秒），这类连接可能被攻击者反复复用，绕过你对应用连接的限制。
生产环境建议统一设为 300～600 秒：
- 设
300（5 分钟）适合高并发、短事务场景，能快速回收空闲连接 - 设
600（10 分钟）更稳妥，兼顾部分需长轮询或延迟提交的业务逻辑 - 修改后旧连接不会立即断开，必须等它们自然空闲超时或重启应用连接池
connect_timeout 要防慢握手攻击，但别盲目调大
connect_timeout 控制的是 TCP 握手 + 认证阶段的等待上限，不是已建立连接的空闲时间。攻击者可能发起大量半开连接（SYN flood 或认证卡在密码校验），拖慢服务器响应。
默认值通常为 10 秒，够用；若网络链路差或用了强认证插件（如 PAM、LDAP），可临时调到 15，但不要超过 30：
- 超过
30秒，攻击者一个 IP 就能持续占用连接槽位数分钟 - 配合
max_connect_errors使用：设为3，连续失败后封 IP（需开启skip-name-resolve避免 DNS 拖慢判断） - 该参数无法通过
SET GLOBAL动态修改，必须写入配置文件并重启 MySQL
MAX_USER_CONNECTIONS 是第一道隔离墙，不是摆设
单个用户账号的连接上限由 MAX_USER_CONNECTIONS 控制，它比全局 max_connections 更精准——攻击者即使拿到一个低权限账号，也无法靠它打满整个数据库。
设置方式必须用 ALTER USER，不能靠 SET GLOBAL max_user_connections：
-
ALTER USER 'app'@'192.168.1.%' WITH MAX_USER_CONNECTIONS 5;立即生效 - 设为
0表示不限（受全局max_connections约束），不推荐 - 验证是否生效：查
mysql.user表，不是看SHOW PROCESSLIST（历史连接不计入限制校验） - 连接池配置（如 HikariCP 的
maximumPoolSize）必须 ≤ 这个值，否则启动就报ERROR 1226
net_read_timeout 和 net_write_timeout 防止“假连接”挂死
当连接已建立但客户端突然断网、崩溃或恶意不发数据时，MySQL 会卡在读/写阻塞状态，这类连接显示为 Sleep 但 Time 持续增长，实际已失效。
net_read_timeout 和 net_write_timeout 就是管这个的：
-
net_read_timeout默认30秒，建议设为60～120，适应慢查询或大结果集分页 -
net_write_timeout默认60秒，一般不用动；若应用频繁导出大文件，可提到300 - 这两个值太小会导致正常长查询被中断，太大则僵尸连接长期占位——关键是要和应用层 socketTimeout 对齐
- 它们同样需要写入配置文件重启生效，
SET GLOBAL在部分 MySQL 版本中不支持动态修改
wait_timeout 就立刻断开，得靠它们自己空闲够久，或者被应用主动 close。所以配置完，一定要检查 SHOW PROCESSLIST 中的 Sleep 连接 Time 值是否在下降，而不是只信 SHOW VARIABLES 返回的数字。
