MySQL会话空闲超时由wait_timeout（非交互式连接）和interactive_timeout（交互式连接）控制，绝大多数业务连接受wait_timeout影响，默认28800秒，需结合连接池配置共同调整。
MySQL会话空闲超时由哪个参数控制？
MySQL服务端不区分“业务账号”，只对所有客户端连接统一应用空闲超时策略。真正起作用的是全局系统变量 wait_timeout，它定义了非交互式连接（如应用通过JDBC、PyMySQL等建立的连接）在无任何操作时的最大空闲秒数。交互式连接（如mysql命令行）则受 interactive_timeout 控制，但绝大多数业务连接都属于前者。
-
wait_timeout默认值通常是28800秒（8小时），远高于常见业务需求 - 修改该值不会立即影响已有连接，只对新建立的连接生效
- 它是会话级变量，但不能在用户会话中用 SET 修改（除非有 SUPER 权限，而业务账号不该有）
- 所以“为特定账号设置”只能通过连接建立时的隐式继承 + 应用层配合实现
为什么不能直接给某个MySQL账号单独设超时？
MySQL没有 per-user 的超时配置机制。用户账号本身不携带连接行为参数，wait_timeout 是服务端全局/会话级变量，不是权限表字段。你查 mysql.user 表，找不到任何 timeout 相关列。
- 尝试用
ALTER USER 'biz_app'@'%' ATTRIBUTE '{"wait_timeout": 300}'是无效的——MySQL不解析或使用该字段 - GRANT 语句也不支持 timeout 选项
- 某些云厂商控制台提供的“账号级超时”其实是代理层拦截，非原生MySQL能力
所以所谓“为特定账号设置”，本质是：让该账号的所有连接，在建立时就自动带上期望的 wait_timeout 值——这必须靠客户端驱动或中间件完成。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
应用连接时如何强制指定 wait_timeout？
多数主流驱动支持在连接字符串或初始化参数中传递会话变量。关键不是“设置账号”，而是“让每次 connect 都执行 SET SESSION wait_timeout = N”。
- JDBC：在 connection URL 后加
?sessionVariables=wait_timeout=300 - PyMySQL：初始化时传参
init_command="SET SESSION wait_timeout = 300" - MySQL Connector/Python：同 PyMySQL，用
init_command - Node.js mysql2：在配置对象中加
initialize: ["SET SESSION wait_timeout = 300"] - 连接池（如 HikariCP、DBUtils）需确认是否透传 init_command；部分池子会覆盖或忽略，建议在池配置的
connection-init-sql中显式写入
注意：如果应用先执行了其他语句再 SET，可能已触发超时计时，所以 init_command 或连接参数方式更可靠。
容易被忽略的两个现实问题
- 即使设置了
wait_timeout = 300，若应用层连接池启用了 testOnBorrow 或心跳检测（如 SELECT 1），实际连接永远不会空闲满300秒，超时逻辑形同虚设
- MySQL 5.7+ 对短连接（快速建连+执行+断开）有性能优化，但若应用误配了长生命周期连接 + 低频查询，
wait_timeout 触发断开后，应用若没正确捕获 MySQL server has gone away 错误，就会出现后续请求失败且难以定位
wait_timeout = 300，若应用层连接池启用了 testOnBorrow 或心跳检测（如 SELECT 1），实际连接永远不会空闲满300秒，超时逻辑形同虚设 wait_timeout 触发断开后，应用若没正确捕获 MySQL server has gone away 错误，就会出现后续请求失败且难以定位 真正起效的前提，是业务连接确实会长时间空闲，且应用能妥善处理连接中断重试。否则调这个参数只是掩盖了连接管理设计缺陷。
