最有效手段是为每个应用账号绑定MAX_USER_CONNECTIONS；需对多host账号分别设置，设0表示不限制但生产不建议；配合max_execution_time限制SELECT执行时长，并调小wait_timeout和interactive_timeout至300秒，最后验证mysql.user表及performance_schema.threads中连接数。
直接限制单个用户的最大连接数
最有效、最可控的手段是给每个应用账号绑定 MAX_USER_CONNECTIONS。全局 max_connections 调高只会让问题更隐蔽，而用户级限制能精准隔离风险。
对已有账号用 ALTER USER 修改：
ALTER USER 'api_user'@'%' WITH MAX_USER_CONNECTIONS 15;
注意点：
- 多个 host（如
'api_user'@'192.168.1.%'和'api_user'@'localhost'）必须分别设置，MySQL 视为独立账户 - 设为
0表示不限制（退回到全局上限），生产环境不建议留0 - 执行后无需
FLUSH PRIVILEGES，MySQL 8.0+ 自动刷新
配合服务端执行时间强制中断
仅靠连接数限制挡不住“一个连接反复跑长 SQL”的情况。必须让 SQL 自身在超时后被 MySQL 主动终止，否则连接一直占着不放。
启用 max_execution_time（MySQL 5.7.8+ 支持）：
SET SESSION max_execution_time = 3000; -- 单条 SELECT 最多执行 3 秒
或全局生效（需 SUPER 权限）：
SET GLOBAL max_execution_time = 3000;
关键提醒：
- 该参数只对
SELECT生效，INSERT/UPDATE/DELETE需靠应用层setQueryTimeout()或驱动层socketTimeout - 必须确保账号有
PROCESS权限，否则KILL QUERY操作会被拒绝 - 它和慢查询日志的
long_query_time无关——后者只记录，不中断
检查并收紧空闲连接超时
客户端异常断开后，MySQL 不会立刻回收连接资源，而是等 wait_timeout 或 interactive_timeout 到期。如果这两个值设得过大（比如 24 小时），连接就会长期空转占坑。
推荐设为 300（5 分钟）：
SET GLOBAL wait_timeout = 300;<br>SET GLOBAL interactive_timeout = 300;
但要注意：
- 这个值不能比应用连接池的
idle-timeout还小，否则池里连接可能被 MySQL 先断开，导致后续请求报Connection reset -
interactive_timeout主要影响 mysql CLI 等交互式客户端，一般与wait_timeout同步设置即可 - 应用代码里仍要显式关闭连接——超时只是兜底，不是替代方案
验证配置是否真正起作用
改完配置不验证，等于没做。重点查两处：
第一，确认系统表已写入：
SELECT User, Host, Max_user_connections FROM mysql.user WHERE User = 'api_user';
第二，看当前活跃连接是否被限制住：
SELECT user, COUNT(*) FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND user = 'api_user' GROUP BY user;
如果返回的 COUNT(*) 超过你设的 MAX_USER_CONNECTIONS 值，说明配置未生效或被绕过；如果新连接直接被拒绝（报错 Too many connections for user），才算真正落地。
最容易被忽略的是：用户有多个 host 匹配规则却只改了一个，或者误以为 max_execution_time 对所有语句都生效。真实环境中，这些细节才是防线失效的常见原因。
