必须设在驱动层，mysql的max_execution_time和postgresql的statement_timeout无法兜底：前者仅限select且受版本与配置限制，后者不中断连接且对纯计算逻辑无效；真正覆盖全链路的是jdbc setquerytimeout、psycopg2 execute(timeout)等驱动层超时，须配合参数化查询方可生效。
超时必须设在驱动层，不是数据库配置里
只改 MySQL 的 MAX_EXECUTION_TIME 或 PostgreSQL 的 statement_timeout 是无效兜底。这些服务端参数要么只对 SELECT 生效（MySQL），要么在客户端断连后仍继续执行（PostgreSQL），根本拦不住并发 SLEEP(5) 拖垮连接池。
真正起作用的是驱动层 timeout：
- JDBC：用
PreparedStatement.setQueryTimeout(3)（单位秒），必须在每次execute()前显式调用 - Python psycopg2：
cursor.execute(sql, timeout=3)（单位秒） - Node.js pg：
client.query({ text: sql, timeout: 3000 })（单位毫秒）
漏掉这一层，等于没设——攻击者发 10 个 AND SLEEP(5)，你服务端设了 6 秒超时，照样吃满全部连接。
超时值不能按平均响应时间拍脑袋定
设成 2 秒还是 30 秒，取决于业务场景和攻击成本平衡，不是 DBA 说了算：
- 前端接口：建议
2–3秒。用户刷新页面前的容忍极限就是你的安全窗口 - 后台导出任务：可设
300秒，但必须配合异步机制（如返回 task ID 轮询），否则一个恶意请求就能卡死 HTTP worker - 连接池也要同步收紧：
maxWait和maxActive得随超时值下调，避免线程被占满
超时不是越长越安全，而是越短越能打断批量探测。P95 响应时间 + 攻击者构造延迟的成本，才是决策依据。
参数化查询是前提，超时只是最后一道止损阀
没有参数化，所有超时设置都形同虚设。攻击者可以用 UNION SELECT 或 INSERT INTO ... SELECT 绕过 MAX_EXECUTION_TIME，也能用 WAITFOR DELAY（SQL Server）或 BENCHMARK()（MySQL）逃过驱动层 timeout 的拦截范围。
必须同时满足两个条件：
- 所有用户输入都走
PreparedStatement/cursor.execute(sql, params)等参数化路径 - 驱动层
setQueryTimeout或等效机制已启用且生效（需验证日志或 mock 测试）
只做一半，等于把门锁了却留着窗没关——超时拦得住 SLEEP()，拦不住 INSERT ... SELECT 配合 DNS 外带的数据回传。
MySQL 的 MAX_EXECUTION_TIME 有硬限制
这个参数看着管用，但实际生效要过三道关：
- MySQL 版本必须 ≥
5.7.8，旧版本直接无视 -
optimizer_switch中的max_execution_time不能被显式关闭（某些云厂商 RDS 默认关了） - 仅对
SELECT语句有效；INSERT/UPDATE/DELETE里嵌SLEEP()完全不受控
想强制生效？只能在 SQL 里加提示注释：SELECT /*+ MAX_EXECUTION_TIME(1000) */ * FROM users。但前提是应用层能控制生成的 SQL 文本——ORM 自动拼的语句通常不支持这种写法。
超时值和参数化必须配对落地，缺一不可；驱动层 timeout 设错位置，比不设还危险——它会给你一种“已经防护”的错觉，而真实攻击早绕开了。
