max_execution_time无法限制单个用户，因其仅为会话级变量；需通过代理层注入、应用层初始化或语句级hint（如/+ max_execution_time(2000) /）实现用户级控制。
不能靠 SET GLOBAL max_execution_time 绑定用户——它只按会话生效，不是用户策略。 真正能隔离特定用户的慢查询控制，必须组合应用层注入、语句级 hint 或代理层规则，否则所有用户共享同一套会话默认值。
为什么 max_execution_time 无法直接限制单个用户
这个变量本质是「会话级默认值」：哪怕你给 user_report 新建连接，只要没在连接初始化时显式执行 SET SESSION max_execution_time = 5000，它就继承 global 值；而 user_app 的连接也可能用同一个 global 值。MySQL 本身不提供「对 user_a 的所有 SELECT 强制限 3 秒」的权限级配置。
-
max_execution_time不作用于INSERT/UPDATE/DELETE、存储过程、触发器、复制线程 - 即使在存储过程中
SET SESSION max_execution_time = 100，里面的SELECT SLEEP(5)也不会中断 - 全局设置需
SUPER权限，且只影响新连接，已有连接不受影响
真正可行的三种用户级控制方式
绕过 MySQL 自身限制，把控制点前移到连接建立或语句提交环节：
-
连接池自动注入：在 ProxySQL 或 MaxScale 中配置「匹配用户名 → 注入初始化命令」，例如对
user_analytics自动执行SET SESSION max_execution_time = 10000 -
应用层连接初始化：每次从连接池获取连接后，立刻执行
SET SESSION max_execution_time = 3000（注意：必须搭配 JDBC 的socketTimeout，否则锁等待仍卡住） -
语句级 hint（最可靠）：在 SQL 中写
SELECT /*+ MAX_EXECUTION_TIME(2000) */ * FROM t—— 注释和SELECT之间不能换行或多余空格，否则失效
Hint 优先级最高：即使会话已设 10 秒，hint 写了 2 秒，就按 2 秒走；错误码固定为 ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded。
/*+ MAX_EXECUTION_TIME(N) */ 的实际使用陷阱
这个 hint 看似简单，但生产环境容易踩坑：
- 只对外层
SELECT生效，嵌套子查询里的SELECT不受控 - 如果外层
SELECT调用了含INSERT的函数（哪怕只是写临时表），整个语句被判定为「非只读」，hint 自动失效 - 不支持在
UNION、WITH或视图定义中跨层级传递 - 单位是毫秒，写成
MAX_EXECUTION_TIME(5)表示 5 毫秒——太严可能误杀正常查询
测试时建议先用 SELECT /*+ MAX_EXECUTION_TIME(30000) */ SLEEP(5) 验证是否触发中断，再逐步收紧阈值。
最常被忽略的一点：max_execution_time 和 wait_timeout 完全是两回事——前者管单条 SELECT 执行时长，后者管连接空闲多久断开。两者必须配合使用，否则长事务里查一半就断连，反而更难排查。
