max_execution_time仅对select语句生效，不影响insert/update/delete及存储过程、触发器、复制线程；mysql 5.7默认为0且仅支持会话级设置，8.0起支持全局持久化和max_execution_time提示。
max_execution_time 设置后为什么没生效
这个参数只对 SELECT 语句起作用，INSERT、UPDATE、DELETE 不受它限制。如果你在执行写操作时看到超时，不是它的问题。
另外，它只影响「客户端发起的语句」，不作用于存储过程内部、触发器或从库复制线程里的 SQL。如果用的是 MySQL 5.7，该参数默认为 0（即禁用），必须显式设为正整数才生效。
- 检查当前会话是否覆盖了全局值：
SELECT @@session.max_execution_time, @@global.max_execution_time; - 设置会话级超时（临时）：
SET SESSION max_execution_time = 30000;（单位毫秒） - 设置全局级（需 SUPER 权限）：
SET GLOBAL max_execution_time = 30000; - 永久生效要写进配置文件：
max_execution_time = 30000放在[mysqld]下，然后重启或热加载
和 wait_timeout / interactive_timeout 的区别在哪
wait_timeout 控制的是空闲连接保持时间，不是 SQL 执行耗时；max_execution_time 是单条 SELECT 最大允许运行时长，两者完全无关。混淆它们会导致调错参数，问题依旧。
典型误判场景：应用报 “Lost connection to MySQL server during query”，其实是 max_execution_time 触发中断，但日志里看不到明显错误，只有 Query execution was interrupted 这类提示，容易被当成网络断连。
- 查中断记录：开启
general_log或检查错误日志中是否出现Query execution was interrupted -
wait_timeout超时通常伴随MySQL server has gone away，且发生在无查询的空闲期 - 高并发下慎调大
max_execution_time，否则慢查询堆积可能拖垮整个实例
应用层怎么配合避免被强制中断
数据库端设了超时，应用如果不做对应处理，可能拿到部分结果或异常后直接崩溃。关键是识别中断信号并降级或重试。
例如 Python 的 pymysql 遇到 max_execution_time 中断，抛出的是 OperationalError(1317, 'Query execution was interrupted')，不是超时异常；Go 的 mysql 驱动则返回 context.DeadlineExceeded 错误，但底层原因仍是这个参数。
- 捕获明确错误码 1317，而不是泛泛地 catch timeout 类异常
- 对分析类查询可适当提高该值，但 OLTP 场景建议保持 ≤ 5s，强制走索引或拆分逻辑
- 不要依赖它替代 SQL 优化——它只是兜底，不是性能方案
MySQL 5.7 和 8.0 在行为上的关键差异
MySQL 5.7 中 max_execution_time 仅支持会话级设置，无法设为全局默认；而 8.0 开始支持 SET PERSIST 持久化到 mysqld-auto.cnf，且新增了 MAX_EXECUTION_TIME 查询提示（hint），比如：SELECT /*+ MAX_EXECUTION_TIME(5000) */ * FROM t1;。
注意：hint 的优先级高于会话变量，但低于全局变量（如果有的话）。8.0 还修复了某些子查询嵌套下该参数失效的问题。
- 5.7 升级到 8.0 后，原来靠改会话变量控制超时的代码仍可用，但建议逐步迁移到 hint 方式，更精准
- 使用
SET PERSIST max_execution_time = 5000;后，即使重启也不会丢失，比改配置文件更灵活 - hint 对 prepared statement 无效，动态拼 SQL 时要注意
实际调参前先确认是哪类查询在超时、有没有索引、执行计划是否合理——max_execution_time 是刹车片，不是发动机。
