SQL注入引发的拒绝服务（DoS）本质是攻击者构造低效查询（如嵌套子查询、CROSS JOIN、ORDER BY RAND()）导致数据库线程卡死、连接池耗尽、CPU打满；超时仅是止损阀，必须配合参数化查询、白名单校验、最小权限等根本防护。
SQL注入引发的拒绝服务（DoS）本质是什么
SQL注入导致拒绝服务，不是因为攻击者偷了数据，而是他们构造了故意低效的查询，比如嵌套子查询、大量 CROSS JOIN、或在超大表上强制全表扫描 + ORDER BY RAND()。数据库线程卡死、连接池耗尽、CPU打满，最终新请求全部排队或失败。
这类攻击不依赖漏洞利用链，只要应用拼接 SQL 且没做基础防护，就可能被触发。超时不是兜底方案，而是最后一道“止损阀”。
如何在不同数据库中设置查询级超时
超时必须设在执行层，而非连接层——connection timeout 只管建连，对已执行的慢查询无效。
- MySQL：用
max_execution_time（5.7.8+），仅对SELECT生效，需在语句开头加提示：SELECT /<em>+ MAX_EXECUTION_TIME(3000) </em>/ * FROM users WHERE ...
；或全局设SET SESSION max_execution_time = 3000（毫秒），但无法覆盖所有客户端上下文 - PostgreSQL：用
statement_timeout，单位毫秒，推荐在会话初始化时执行：SET statement_timeout = 3000
；也可在连接字符串中加options=-c%20statement_timeout=3000 - SQL Server：用
COMMAND_TIMEOUT（ADO.NET / JDBC 中设置），或在 T-SQL 中配合SET LOCK_TIMEOUT防锁等待，但注意它不中断正在运行的计算型查询 - 应用层（如 Python + SQLAlchemy）：在
create_engine时传connect_args={"command_timeout": 3}（PostgreSQL）或用execution_options(timeout=3)对单条语句控制
关键点：超时值不能拍脑袋定。先用 EXPLAIN ANALYZE 测正常业务查询的 P95 耗时，再上浮 2–3 倍设为阈值。
为什么只靠超时不够，还必须堵住拼接入口
超时只能让单次攻击失效，但攻击者可并发发起几十个超时查询，照样压垮连接池和内存。真正有效的防线是：
- 彻底禁用字符串拼接 SQL，一律改用参数化查询：
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id]) - 对动态字段/表名等无法参数化的部分，用白名单校验：
if sort_field not in ("created_at", "name"): raise ValueError - 数据库账号最小权限原则：应用账号不应有
CREATE、DROP、LOAD_FILE或跨库查询权限 - 在 Web 层（如 Nginx）加请求频率限制，对含
UNION SELECT、SLEEP(、BENCHMARK(的请求直接拦截
超时是保险丝，不是防火墙。熔断了还得查哪条电路裸奔。
常见配置失效场景与排查建议
超时看似简单，实际常因环境错位而形同虚设：
- JDBC URL 里写了
socketTimeout=3000，但这是网络层超时，对已发送到数据库并开始执行的语句无效 - ORM 框架（如 Django ORM）默认不透传超时参数，需显式调用
.extra(timeout=3)或改用原生查询 - 数据库中间件（如 ProxySQL、MaxScale）可能重写或忽略客户端超时指令，需确认其是否支持并启用了
query_timeout规则 - Kubernetes 中 Pod 重启或连接池未正确 close，会导致旧连接残留，超时设置在新连接生效，但旧连接仍在跑恶意查询
上线前务必用真实慢查询验证：构造一个 SELECT pg_sleep(5) 或 SELECT SLEEP(5)，看是否真能在 3 秒内报错退出。
超时值设太短，误杀正常报表；设太长，DoS 已经发生。平衡点不在文档里，在你自己的慢查询日志里。
