MySQL如何防御慢SQL攻击导致的宕机_设置max_execution_time限制

max_execution_time仅限SELECT语句超时中断对UPDATE/DELETE等无效且默认为0、可被客户端覆盖无法防御真实慢SQL攻击。max_execution_time 是什么为什么它防不住真正的慢SQL攻击max_execution_time 是 MySQL 5.7.8 引入的会话级超时参数单位毫秒作用是「强制中断执行时间超过阈值的 SELECT 语句」。但它只对 SELECT 生效对 UPDATE、DELETE、INSERT ... SELECT 完全无效而且默认为 0不限制即使你全局设了客户端连接仍可覆盖它。真实攻击者发一条没加 LIMIT 的 UPDATE t1 JOIN t2 ON ... SET t1.x 1max_execution_time 就彻底失能。常见错误现象SET GLOBAL max_execution_time 1000 后监控里还是出现 30 秒的 UPDATE 占满 CPU。它不阻塞连接建立只干预正在执行的 SELECT事务内语句超时后事务不会自动回滚可能留下脏状态PHP/Python 等客户端若未捕获 Query execution was interrupted 错误会静默失败或重试反而加剧负载真正有效的三道防线从连接层到语句层靠单一参数拦不住慢 SQL 攻击得组合控制连接准入层用 max_connections wait_timeout 防连接堆积比如设 wait_timeout 60避免空闲连接长期占着线程资源限制层给高风险账号配 MAX_STATEMENT_TIMEMySQL 8.0.12或 MAX_EXECUTION_TIMEPercona Server它比会话变量更可靠且支持非 SELECT语句拦截层在代理层如 ProxySQL、MaxScale配置规则直接拒绝无 WHERE 的 UPDATE/DELETE或匹配 JOIN ORDER BY 无 LIMIT 的 SELECT示例ProxySQLINSERT INTO mysql_query_rules (active, match_pattern, error_msg) VALUES (1, UPDATE.*WHERE, No WHERE clause allowed); 灵办AI 免费一键快速抠图支持下载高清图片