MySQL防止慢SELECT应设max_execution_time（仅对SELECT生效），而wait_timeout只控制空闲连接；DML超时需应用层timeout或KILL QUERY配合监控，且须注意配置位置、权限及事务锁资源问题。
MySQL 全局查询超时用 wait_timeout 还是 max_execution_time？
两者完全不是一回事：wait_timeout 控制的是**空闲连接**的断开时间（比如应用发完一条 SQL 后就再也不说话了），对正在执行的 SELECT/UPDATE 等毫无影响；真正能中断慢查询的是 max_execution_time，但它默认为 0（即不限制），且**仅对 SELECT 生效**（INSERT/UPDATE/DELETE 不吃这套）。
所以如果你的目标是“防止一个 SELECT 跑 10 分钟把 CPU 和锁占死”，必须显式设置 max_execution_time，而且得在会话级或全局级打开它：
SET GLOBAL max_execution_time = 30000; -- 单位毫秒，即 30 秒
注意：该变量从 MySQL 5.7.8 引入，低版本不支持；重启后失效，需写入配置文件才能持久化。
如何让 INSERT/UPDATE/DELETE 也受超时控制？
MySQL 原生不提供 DML 语句级执行超时。绕过方法只有两个，且都带代价：
-
应用层加 timeout：比如 Python 的
mysql-connector-python支持connection_timeout和read_timeout，但它们管的是网络等待，不是 SQL 执行中止；真正靠谱的是用cursor.execute(..., timeout=30)（需驱动支持），或自己起线程+信号中断（复杂且有风险） -
用
KILL QUERY配合监控：定期查information_schema.PROCESSLIST，筛选TIME > 30 AND COMMAND != 'Sleep'的线程，再调用KILL QUERY <id></id>。缺点是存在检测窗口期，且 KILL 本身可能被阻塞（比如目标线程正持有锁）
没有银弹。DML 超时本质是业务逻辑问题——长事务不该靠数据库兜底，而应拆分、加 LIMIT、避免单次操作百万行。
配置写进 my.cnf 后为什么没生效？
常见原因有三个：
-
max_execution_time是动态变量，但**不能写进[mysqld_safe]或[client]段**，必须放在[mysqld]下，否则启动时直接忽略 - 变量名拼错：有人写成
max_execution_timeout或execution_time_limit，MySQL 不报错但静默跳过 - 权限不足：
SET GLOBAL需要SUPER或SYSTEM_VARIABLES_ADMIN权限；配置文件生效还需确保 mysqld 启动用户有读取权限，且没有被 systemd 的ProtectHome=yes拦截
验证是否生效，别只看配置文件，直接连上去查：
SELECT @@global.max_execution_time;
长事务锁定资源，光设超时远远不够
超时只能杀掉“正在跑”的语句，但解决不了“已拿到锁却迟迟不提交”的事务。这类事务哪怕只执行了一条 UPDATE，也可能锁住整张表几小时。
真正要防的是事务生命周期失控，必须组合手段：
- 应用层强制设置事务最大持续时间（比如 Spring 的
@Transactional(timeout = 30)） - DBA 定期跑脚本查
INFORMATION_SCHEMA.INNODB_TRX，过滤TRX_STARTED早于当前时间 60 秒的事务并告警 - 禁止在事务里做 HTTP 调用、文件读写等外部依赖操作
超时参数只是最后一道闸门，不是安全带。锁住资源的从来不是慢查询，而是忘记 COMMIT 的人。
