interactive_timeout仅控制交互式连接，如mysql -u root -p、mysql shell、workbench等人工操作会话；不控制jdbc、pymysql等应用连接，后者由wait_timeout管理；修改需同步设置二者并重启服务才生效。
interactive_timeout 控制哪些连接？
它只管你手动敲命令的连接：比如 mysql -u root -p、MySQL Shell、Workbench 这类工具建立的会话。JDBC、PyMySQL、Node.js 的 mysql2 等应用连接完全不走这个参数——它们看的是 wait_timeout。
常见错误现象：
- 你在终端连上 MySQL，5 分钟没输任何命令，直接断开 → 是
interactive_timeout在起作用 - Spring Boot 应用隔几分钟报
Lost connection to MySQL server during query→ 和interactive_timeout无关，得查wait_timeout和连接池配置
怎么改才真正生效？
临时改（仅对后续新建的交互式连接有效）：
SET GLOBAL interactive_timeout = 600;
注意：需要 SUPER 或 SYSTEM_VARIABLES_ADMIN 权限；已存在的连接不受影响。
永久改（生产环境唯一推荐方式）：
编辑 MySQL 配置文件（Linux 下是 /etc/my.cnf 或 /etc/mysql/my.cnf，Windows 是 my.ini），在 [mysqld] 段下写：
[mysqld] interactive_timeout = 600 wait_timeout = 600⚠️ 必须同时设
wait_timeout，否则两者不一致会导致连接行为混乱（比如你命令行连着，同一账号的应用连接却被提前踢掉）。
改完必须重启服务：systemctl restart mysqld（Linux）或 net stop mysql80 && net start mysql80（Windows）。仅 RELOAD 不生效。
为什么单独调大 interactive_timeout 常常没用？
- MySQL Workbench、DBeaver 这类 GUI 工具自带心跳或自动重连，根本等不到服务端超时；
- SSH 终端本身有空闲断开设置（如 ClientAliveInterval），往往比 MySQL 层更早切断连接；
- 云数据库（阿里云 RDS、腾讯云 CDB）通常禁用该参数修改，或修改后不生效——背后是连接池代理在控制真实超时；
- 即使设了 600 秒，中间若有 NAT、防火墙、SLB，它们自己的空闲超时（常见 300 秒）会先斩断 TCP 连接，MySQL 根本来不及触发逻辑。
验证是否生效：
登录后执行 SHOW VARIABLES LIKE 'interactive_timeout';，确认返回值是你设的数字；再新开一个命令行连接，不输入任何命令，等时间过去看是否自动退出。
