MySQL 5.7.8+ 可通过 MAX_EXECUTION_TIME 限制 SELECT 查询执行时长，支持会话级、全局级及配置文件设置，仅对 InnoDB/MyISAM 表生效，超时后状态显示 Killed；不作用于 DML、存储过程内部语句及优化阶段，且受锁等待、引擎不支持或客户端超时影响。
MySQL 5.7+ 怎么用 MAX_EXECUTION_TIME 限制单条查询耗时
直接生效，不需要改应用代码，但只对支持的存储引擎（InnoDB、MyISAM）和查询类型起作用。它本质是服务端超时机制，在执行器层面掐断长时间运行的 SELECT，避免拖垮整个连接池。
启用方式分两层：
- 会话级：执行
SET SESSION MAX_EXECUTION_TIME = 3000（单位毫秒），后续该连接的所有 SELECT 受限 - 全局级：执行
SET GLOBAL MAX_EXECUTION_TIME = 3000，新建立的连接默认继承该值（已存在的连接不受影响） - 启动参数：在
my.cnf中加max_execution_time=3000，重启后永久生效
注意：MAX_EXECUTION_TIME 对 INSERT/UPDATE/DELETE 无效，也不影响存储过程内部的语句——它只管最外层的 SELECT。
为什么有些慢查询没被 MAX_EXECUTION_TIME 拦住
常见漏网原因有三个：
- 查询还没走到执行阶段就卡住了，比如锁等待（
Waiting for table metadata lock或Waiting for lock），此时计时器根本没启动 - 用了不支持该特性的引擎，比如 MEMORY 或 CSV 表；或者查询包含
UNION且部分分支走的是临时表合并逻辑 - 客户端设置了
net_write_timeout或wait_timeout，连接先被中断了，MySQL 根本没机会触发执行超时
验证是否生效，可查 SHOW PROCESSLIST，被超时的查询状态会显示为 Killed，错误日志里出现 Query execution was interrupted。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
和 long_query_time、pt-kill 的关系怎么理清
三者定位完全不同：
-
long_query_time是日志开关，只记录慢查询，不干预执行；设成 1 秒，不代表超过 1 秒就停，只是写进慢日志 -
MAX_EXECUTION_TIME是主动熔断，到点立刻终止，但仅限 SELECT，且依赖执行器调度 -
pt-kill是外部工具，靠轮询PROCESSLIST杀连接，能覆盖所有语句类型，但有延迟（默认 30 秒检查一次），还可能误杀正在做事务回滚的连接
生产环境建议组合用：MAX_EXECUTION_TIME 防 SELECT 挂死 + pt-kill 扫描并干掉卡在锁或网络上的连接。
上线前必须确认的兼容性细节
MySQL 5.7.8 才正式引入该功能，5.6 及更早版本不识别这个变量，设了也无效；8.0.2 开始支持在 SELECT 语句末尾加 /*+ MAX_EXECUTION_TIME(3000) */ 提示，优先级高于会话设置。
另一个容易忽略的点：MAX_EXECUTION_TIME 不影响查询优化阶段耗时。如果一条 SQL 光是生成执行计划就花了 5 秒（比如涉及上百张表 JOIN），它不会被中断——超时只从“开始读取第一行数据”那一刻才开始计。
