错误原因为max_execution_time参数过小导致select查询超时中断，解决方法是调大该值或设为0（不限制），且该参数仅作用于独立select语句，不作用于存储过程、insert select等。
查错误日志里有没有 ERROR 3024
这是最直接的证据。max_execution_time 触发中断时，MySQL 会写入错误日志（不是 general_log），固定报错：ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded。
别指望它出现在 slow_query_log 或 application log 里——除非你应用层显式捕获并打点。用 grep "ERROR 3024" /var/log/mysql/error.log 快速确认是否真有这类中断。
确认被中断的是 SELECT 还是其他语句
max_execution_time 只对独立执行的 SELECT 生效，INSERT、UPDATE、DELETE、存储过程内部语句、函数、触发器里的查询全都不受控。如果你看到 UPDATE 被中断，那一定不是它干的——可能是 innodb_lock_wait_timeout 或 KILL 导致的。
检查方式：
• 查 SHOW PROCESSLIST 中状态为 Query execution was interrupted 的线程，看它的 Info 字段是不是以 SELECT 开头
• 对比 SELECT @@session.max_execution_time 和实际执行语句类型，避免误判
看事务是否还在 RUNNING 状态
max_execution_time 中断后，语句终止，但**事务不会自动回滚**。如果该 SELECT 在事务中（比如前面有 BEGIN 或 autocommit=0），那么事务仍处于活跃状态，锁还挂着，后续语句可能被阻塞。
验证方法：
• 执行 SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING'
• 检查 trx_started 时间是否早于 ERROR 3024 日志时间
• 对应线程 ID 是否在 PROCESSLIST 中显示为 Sleep 或 Waiting for table metadata lock
这种情况容易引发隐性阻塞，比单纯超时更难察觉
排除 hint 被静默忽略的情况
用了 /*+ MAX_EXECUTION_TIME(5000) */ 却没生效？常见原因：
• 当前用户缺少 PROCESS 权限 —— hint 会被 MySQL 直接跳过，不报错也不生效
• 语句不是纯 SELECT：比如 INSERT SELECT、SELECT ... INTO OUTFILE、带子查询的 UPDATE，这些都不算“独立 SELECT”
• 查询卡在锁等待阶段（如等行锁）：max_execution_time 计时包含锁等待时间，但若锁一直拿不到，可能超时后仍卡住 —— 此时实际错误是 Lock wait timeout exceeded，不是 3024
• MySQL 版本低于 5.7.8：SELECT VERSION() 必须先跑一遍
真正麻烦的不是中断本身，而是中断后事务没结束、锁没释放、连接还占着——这种“半死不活”的状态最容易漏掉，也最难定位。
