必须设为相同值，因非交互式连接（如JDBC）初始化时继承interactive_timeout值，若二者不一致会导致应用连接沿用旧值被断开；生产建议统一设为300～600秒，并同步校准连接池maxLifetime与健康检查。
wait_timeout 和 interactive_timeout 必须设为相同值
MySQL 不会自动让这两个参数同步生效。如果只改 wait_timeout 而漏掉 interactive_timeout，命令行登录的连接仍会保持默认 28800 秒（8 小时），这类连接可能被攻击者反复复用，绕过你对应用连接的限制。
生产环境建议统一设为 300～600：
-
300（5 分钟）适合高并发、短事务场景，能快速回收空闲连接 -
600（10 分钟）更稳妥，兼顾部分需长轮询或延迟提交的业务逻辑 - 修改后旧连接不会立即断开，必须等它们自然空闲超时，或重启应用连接池
connect_timeout 控制握手阶段，不是空闲超时
connect_timeout 管的是 TCP 握手 + 认证阶段的等待上限，不是已建立连接的空闲时间。攻击者可能发起大量半开连接（SYN flood 或卡在密码校验），拖慢服务器响应。
默认值通常为 10 秒，够用；若网络链路差或用了强认证插件（如 PAM、LDAP），可临时调到 15，但不要超过 30：
- 超过
30秒，一个 IP 就能持续占用连接槽位数分钟 - 该参数无法通过
SET GLOBAL动态修改，必须写入配置文件并重启 MySQL - 配合
max_connect_errors使用：设为3，连续失败后封 IP（需开启skip-name-resolve避免 DNS 拖慢判断）
客户端连接池必须和 wait_timeout 对齐
光调服务端没用。如果 HikariCP 池子以为连接还活着，而 MySQL 已在 5 分钟后把它关了，下一次取连接就会报 Lost connection to MySQL server during query。
实操要点：
- HikariCP：设
connection-test-query=SELECT 1（MySQL 8.0.22+ 推荐用connection-init-sql），validation-timeout=3000，并启用test-on-return=true - Druid：开启
testWhileIdle=true，设timeBetweenEvictionRunsMillis=30000（30 秒检测一次） - PyMySQL/MySQLdb：确保使用
ping(True)检测连接，或设autocommit=True避免事务卡住连接
MAX_USER_CONNECTIONS 是第一道隔离墙
单个用户账号的连接上限由 MAX_USER_CONNECTIONS 控制，它比全局 max_connections 更精准——攻击者即使拿到一个低权限账号，也无法靠它打满整个数据库。
设置方式必须用 ALTER USER：
-
ALTER USER 'app'@'192.168.1.%' WITH MAX_USER_CONNECTIONS 5;立即生效 - 设为
0表示不限（受全局max_connections约束），不推荐 - 验证是否生效：查
mysql.user表，不是看SHOW PROCESSLIST（历史连接不计入限制校验） - 连接池配置（如 HikariCP 的
maximumPoolSize）必须 ≤ 这个值，否则启动就报 ERROR
wait_timeout 和 interactive_timeout 的一致性、客户端连接池的健康检查节奏、以及 MAX_USER_CONNECTIONS 与池大小的硬约束关系——三者缺一，超时配置就形同虚设。 
