必须将wait_timeout和interactive_timeout设为相同值，否则交互式连接仍按默认28800秒保持空闲，易被滥用；生产环境建议统一设为300或600秒，并同步调整连接池maxlifetime小于该值至少30秒。
wait_timeout 和 interactive_timeout 必须设为相同值
MySQL 不会自动同步这两个参数。只改 wait_timeout 而漏掉 interactive_timeout，命令行、Navicat 或其他交互式工具建立的连接仍按默认 28800 秒（8 小时）保持空闲，攻击者可反复复用这类“长命”连接绕过你对应用连接的限制。
生产环境建议统一设为 600（10 分钟）或 300（5 分钟）：
-
300更适合高并发、短事务场景，能更快释放空闲连接 -
600更稳妥，兼容部分需轮询或延迟提交的业务逻辑 - 旧连接不会立即断开，必须等自然超时或重启应用连接池
connect_timeout 是防慢握手的第一道防线
connect_timeout 控制的是 TCP 握手 + 认证阶段的最大等待时间，不是已建立连接的空闲时间。它专门防 SYN flood、密码暴力尝试、DNS 卡顿等“半开连接”攻击。
默认值通常为 10，够用；但别盲目调大：
- 网络差或用了 PAM/LDAP 插件时，可临时设为
15 - 绝对不要超过
30：一个恶意 IP 就能持续占用线程槽位数分钟 - 必须配合
max_connect_errors = 3使用，且开启skip-name-resolve避免 DNS 拖慢封禁判断 -
connect_timeout无法通过SET GLOBAL动态修改，必须写入配置文件并重启 MySQL
MAX_USER_CONNECTIONS 要真设，不能只靠 max_connections
全局 max_connections 是总闸门，MAX_USER_CONNECTIONS 才是隔离墙——攻击者即使只拿到一个低权限账号，也无法靠它打满整个数据库。
设置方式必须用 ALTER USER：
-
ALTER USER 'app'@'192.168.1.%' WITH MAX_USER_CONNECTIONS 5;立即生效 - 设为
0表示不限（受max_connections约束），不推荐 - 验证是否生效：查
mysql.user表，不是看SHOW PROCESSLIST（历史连接不参与限制校验） - 连接池的
maximumPoolSize（如 HikariCP）必须 ≤ 这个值，否则启动就报ERROR 1226
net_read_timeout 和 net_write_timeout 防“假连接”挂死
当客户端突然断网、崩溃或恶意不发数据时，MySQL 可能卡在 read() 或 write() 系统调用上，连接状态显示为 Sleep 但 Time 持续增长——这种连接已失效，却占着线程和内存。
net_read_timeout 和 net_write_timeout 就是管这个的：
-
net_read_timeout默认30，建议设为60～120，适应慢查询或大结果集分页 -
net_write_timeout默认60，一般不用动；若应用频繁推送大 BLOB，可酌情上调 - 它们不影响空闲连接清理，只影响已建立连接上的读写阻塞行为
- 修改后无需重启，
SET GLOBAL即可生效
wait_timeout = 600，HikariCP 的 maxLifetime 就得设成 540000（9 分钟），否则照样拿到已被服务端关闭的连接，下一次使用直接报 MySQL server has gone away。
