max_execution_time仅对SELECT语句生效，INSERT/UPDATE/DELETE不生效；其优先级为语句级>会话级>全局级；超时后不报错而仅断开查询并返回警告。
max_execution_time 在 MySQL 里到底管不管用
它只对 SELECT 语句生效，INSERT、UPDATE、DELETE 都不认这个参数。哪怕你在会话里设了 SET SESSION max_execution_time = 1000，执行一个卡死的 UPDATE 也不会自动中断——这是最常被误解的一点。
真正起作用的场景是：复杂联表查询、没走索引的全表扫描、临时表过大导致排序慢的 SELECT。如果你的超时问题出在写操作上，得换别的思路，比如检查锁等待、事务隔离级别或加 LOCK IN SHARE MODE 控制并发。
怎么设置才真正生效
三个地方都可能被覆盖，顺序是：语句级 > 会话级 > 全局级。优先级高的一旦设了，低的就无效。常见踩坑是只改了全局变量 max_execution_time，但应用连接池一上来就执行 SET SESSION 覆盖掉了，结果发现根本没用。
-
SET GLOBAL max_execution_time = 5000：影响后续新连接，默认值为 0（不限制） -
SET SESSION max_execution_time = 2000：只对当前连接有效 -
SELECT /*+ MAX_EXECUTION_TIME(1500) */ * FROM orders JOIN users ...：语句级提示，优先级最高，MySQL 5.7.8+ 支持
注意：全局设置需要 SUPER 权限；语句级提示不能和 SQL_NO_CACHE 等其他 hint 冲突；如果查询被优化器重写（比如子查询转成 JOIN），提示可能失效。
超时后的行为不是“报错”，而是“断开查询”
MySQL 不会抛出类似 Query execution was interrupted 的错误给客户端，而是直接关闭该语句的执行流程，返回一个带警告的状态。很多 ORM（比如 Django 的 cursor.execute() 或 SQLAlchemy）默认忽略警告，看起来就像“查不到数据”或“空结果”，而不是明确失败。
验证是否真触发了超时：
- 查
SHOW WARNINGS，看有没有Warning 1317 Query execution was interrupted - 开启慢查询日志，加上
log_queries_not_using_indexes=OFF和long_query_time=0，再抓取实际执行时间 - 用
performance_schema.events_statements_history查TIMER_WAIT和MESSAGE_TEXT
别依赖客户端是否报错来判断——得主动查警告或性能表。
替代方案比硬设 max_execution_time 更可靠
当业务逻辑本身就很复杂（比如报表导出、后台任务），靠 max_execution_time 只是“止痛”，不是“治病”。容易被绕过，也难调试。
- 在应用层加超时控制：比如 Python 用
concurrent.futures.TimeoutError包裹查询，Go 用context.WithTimeout - 拆分大查询：把
SELECT ... JOIN ... WHERE ...拆成主键 ID 列表 + 分批IN查询，避免单次执行不可控 - 用
EXPLAIN FORMAT=TREE看执行计划，确认是否真的走了索引；有时加个FORCE INDEX比调参更立竿见影 - 对于长期运行的分析类查询，考虑迁移到 ClickHouse 或物化视图预计算，别硬扛在 OLTP 数据库上
真正麻烦的从来不是设个数字，而是你没法预判哪条 SELECT 会在哪次数据量突增时突然变慢——所以监控 + 计划 + 应用层兜底，比寄希望于一个会话变量实在得多。
