MySQL 8.0 不支持为单个账号设置独立的 wait_timeout 或 interactive_timeout，因这些变量仅支持全局或会话级配置，无用户粒度存储机制，资源组也不干预超时逻辑。
MySQL 8.0 不支持为单个账号设置独立的 wait_timeout 或 interactive_timeout
直接回答：MySQL 8.0 的原生变量（如 wait_timeout、interactive_timeout）是全局或会话级的，**不能按用户粒度配置**。你无法像 CREATE USER ... FAILED_LOGIN_ATTEMPTS 5 那样，用一条语句给某个账号指定专属超时值。
原因在于：这些 timeout 变量只在连接建立后由客户端或服务端初始化时继承自全局值，后续会话内可 SET SESSION 覆盖，但无法绑定到账户定义中持久生效。MySQL 没有提供类似 user_variables 或 account_timeout 的账户元数据字段。
资源组（Resource Groups）不控制连接超时，只限制 CPU 和线程优先级
MySQL 8.0 引入的 RESOURCE GROUP 功能（需企业版或 MySQL 8.0.2+ 社区版支持）用于绑定线程到 CPU 核心、设置 CPU 带宽配额和优先级，但它**完全不感知或干预连接生命周期、空闲断开、超时逻辑**。
常见误解是以为资源组能“限流”连接时长，实际它对以下行为无影响：
-
wait_timeout/interactive_timeout触发的自动断连 -
connect_timeout（TCP 握手阶段） -
idle_transaction_timeout（事务空闲） - 任何基于时间的连接清理机制
资源组只作用于已建立连接且正在执行语句的线程——一旦连接进入 SLEEP 状态，资源组就不再参与调度或计时。
真正可行的账号级超时控制：靠应用层连接池 + 会话初始化脚本
若必须让不同账号表现出不同超时行为，唯一稳定路径是：在每次连接成功后，由客户端主动执行 SET SESSION 设置对应 timeout 值。这需要配合连接池支持「连接初始化 SQL」功能：
-
Java / HikariCP：配置
connection-init-sql=SET SESSION wait_timeout = 60 -
Python / PyMySQL：传参
init_command="SET SESSION wait_timeout = 60" -
Go / mysql-driver：在 DSN 后加
&initstmt=SET%20SESSION%20wait_timeout%3D60
关键点：
- 必须用
SET SESSION，SET GLOBAL对当前连接无效 - 该设置仅对本次连接有效，断开即丢弃
- 账号本身不存储该值，但连接池可按账号分组配置不同 init_sql
- 需确保应用连接池启用「测试连接有效性」，避免复用已超时断开的连接
容易被忽略的陷阱：wait_timeout 和 interactive_timeout 的实际生效逻辑
很多线上问题源于混淆这两个变量的触发条件：
-
wait_timeout控制 JDBC、ORM、Web 应用等**非交互式连接**（即程序连接），默认继承自全局值，但客户端驱动可能覆盖（如 MySQL Connector/J 默认设为 8 小时） -
interactive_timeout仅影响mysql命令行等**交互式连接**，普通应用几乎不会触发它 - 如果客户端连接时显式发送了
CLIENT_INTERACTIVEflag（极少见），才会走interactive_timeout分支 -
SET PERSIST只能持久化全局变量，不能为每个账号生成独立的持久化记录
所以检查超时是否生效，一定要用 SHOW VARIABLES LIKE 'wait_timeout' 在目标应用连接里查，而不是只看 GLOBAL 值。
