max_execution_time 仅在 MySQL 5.7.8+ 原生服务端对 SELECT 语句生效，不中断 UPDATE/DELETE/INSERT；计时始于执行器阶段，不包含锁等待等时间，触发后报错 1317 且不自动回滚。
max_execution_time 在 MySQL 5.7+ 才真正可用
MySQL 5.6 及更早版本虽然有 max_execution_time 系统变量，但仅对 SELECT 语句在 *optimizer trace* 或某些特定执行路径下生效，实际无法可靠中断慢查询。真正在服务端强制终止超时查询，必须用 MySQL 5.7.8+（含 8.0），且需确保使用的是原生 MySQL Server —— Percona Server 和 MariaDB 的行为不完全一致，别默认等价。
常见错误现象：SET SESSION max_execution_time = 1000 后执行一个明显卡住的 SELECT SLEEP(5) 却没被杀掉，大概率是版本太低或用了不兼容分支。
- 确认版本：
SELECT VERSION()，输出至少为5.7.8或更高 - 检查是否启用：运行
SELECT @@max_execution_time，返回非零值才表示当前会话已激活 - MariaDB 用户注意：它用的是
max_statement_time（毫秒），语法和语义都不同，不能混用
它只对 SELECT 生效，UPDATE/DELETE/INSERT 不受控
max_execution_time 是个“读操作限速器”，不是“全语句熔断开关”。哪怕你设了 SET SESSION max_execution_time = 100，一条跑 30 秒的 UPDATE ... WHERE ... 依然会完整执行到底 —— 它根本不会被中断。
这导致一个典型误用场景：DBA 想防大更新拖垮数据库，却只配了 max_execution_time，结果毫无作用。真正要控写操作，得靠其他机制：
- 应用层加超时（如 JDBC 的
socketTimeout+queryTimeout） - 用
KILL QUERY [connection_id]配合外部监控脚本主动干预 - MySQL 8.0.23+ 可考虑
SET STATEMENT max_execution_time = 100 FOR UPDATE ...，但仅限单条语句，且仍不覆盖所有 DML 场景
全局设置不等于自动生效，SESSION 级才起作用
SET GLOBAL max_execution_time = 1000 这条命令本身不会让后续所有连接自动继承该值。它只是改了全局变量的默认值，新连接是否采用，取决于是否显式执行 SET SESSION max_execution_time = ...，或者应用是否在连接初始化时主动设置了该 session 变量。
也就是说：你改了 global，但 PHP 的 PDO、Python 的 pymysql 默认都不会读这个值，也不会自动 set session —— 它们连这个变量名都不认识。
- 安全做法是在应用建连后立刻执行一次
SET SESSION max_execution_time = 3000 - 如果用连接池（如 ProxySQL、MaxScale），可在其配置中注入初始化命令
- 注意权限：
SET SESSION不需要特殊权限，但SET GLOBAL需要SUPER或SYSTEM_VARIABLES_ADMIN，别在应用里硬写 global 设置
它杀的是语句执行阶段，不是网络等待或锁等待
max_execution_time 计时起点是语句进入执行器（executor）之后，不包括解析、优化、网络传输、行锁等待、MDL 锁等待这些时间。所以你会看到一种“超时失效”的情况：一条 SELECT 明明卡在等表锁，max_execution_time 却迟迟不触发 —— 因为它还没开始“执行”。
这种设计决定了它不适合对抗高并发下的锁争用问题，更适合过滤掉那些本就不该存在的、纯计算/扫描型慢查询。
- 若想捕获锁等待类超时，得看
innodb_lock_wait_timeout（默认 50 秒）和lock_wait_timeout -
max_execution_time触发后报错是Query execution was interrupted（错误号 1317），应用需识别并处理该错误码 - 它不会释放已持有的锁，被中断的事务仍处于 active 状态，需应用主动 rollback，否则可能阻塞别人
事情说清了就结束。
