Python 慢查询的自动降级方案

time.sleep()不能当降级开关，因其仅增加延迟而非中断查询；真实降级需在sql执行前预判、执行中中断、执行后裁剪，依赖驱动层超时机制（如asyncpg的query-level timeout）或sqlite的progress_handler协作中断，并配合上下文化错误返回与日志追踪。

为什么 time.sleep() 不能当降级开关用

慢查询自动降级不是“超时就跳过”，而是“该查的查，不该耗的不耗”。直接在数据库操作前后塞 time.sleep(0.1) 或用 threading.Event.wait() 模拟阻塞，只会让请求更卡、超时更早、线程池更快打满。

真实场景里，降级发生在：SQL 执行前（预判）、执行中（中断）、执行后（结果裁剪）。python 生态里最可控的介入点是数据库驱动层或 ORM 的钩子，而不是靠时间戳硬等。

• postgresql 用 psycopg2 时，cursor.execute() 支持 timeout 参数，但仅限 socket 级超时，对已发到服务端却卡住的查询无效
• mysql 的 pymysql 没有原生查询级 timeout，得靠 socket.settimeout() 配合 signal.alarm()（linux only）或 concurrent.futures.TimeoutError 包裹，但后者会杀线程，不安全
• django 的 QuerySet 不暴露底层 cursor，强行加 timeout 得重写 DatabaseWrapper，维护成本高

asyncpg 的 execute() 怎么设真正有效的查询超时

asyncpg 是少数原生支持查询级 timeout 的 Python DB 驱动。它的 timeout 参数作用于整个查询生命周期——从发送命令、等待响应、到接收结果，超时即抛 asyncpg.exceptions.QueryCanceledError，服务端也会主动终止该查询。

注意它和 asyncio.wait_for() 的区别：wait_for 只 cancel 协程，不通知 PostgreSQL；而 asyncpg 的 timeout 会发 CancelRequest 包，清掉服务端的 backend 进程。

立即学习“Python免费学习笔记（深入）”；

• 必须传 Float 秒数，比如 await conn.execute(sql, timeout=1.5)，不能传 timedelta
• 超时后连接仍可用，但需手动 conn.reset() 清理状态（尤其用了 prepared statement 时）
• 若 SQL 含多个语句（如函数调用+INSERT），timeout 对整条语句生效，不是每个子步骤单独计时

同步代码里怎么安全地给 sqlite3 加降级兜底

sqlite3 没有服务器进程，timeout 只能靠 connect(..., timeout=5.0) 控制“等待锁”的时间，对慢查询本身无效。真要降级，得靠 set_progress_handler() 或 set_trace_callback() 在执行中插桩。

set_progress_handler() 每执行 N 条虚拟机指令就回调一次，适合粗粒度打断；set_trace_callback() 则每执行一条 SQL 语句就触发，开销大但精准。两者都得配合外部标志位（如 threading.Event）做协作式中断。

• 别用 sys.settrace() 或信号中断，SQLite C 层不保证可重入
• progress_handler 的 n 值建议设 1000～5000，太小拖慢正常查询，太大起不到及时中断效果
• 回调函数里只能做轻量判断（如检查 event.is_set()），不能调用任何 SQLite API，否则死锁

降级后返回什么数据才不算“假成功”

返回空列表、默认值或缓存旧数据，看似快了，但可能掩盖业务逻辑断裂。比如用户订单页降级后显示“暂无订单”，实际只是最近 3 天查询超时——这会导致客服投诉激增。

真正的降级策略得带上下文：明确告诉上层“这部分数据不可用”，而不是静默补零。Django 中可用 QuerySet.none() + 自定义异常；fastapi 中建议用 HTTPException(status_code=206, detail="partial_data") 配合结构化响应体。

• 避免把降级逻辑藏在 DAO 层返回 None，上层无法区分“真为空”和“查失败”
• 缓存兜底必须带 stale-while-revalidate 语义，比如 redis 存两份：一份带 TTL 的热数据，一份带更长 TTL 的 stale 数据 + 时间戳字段
• 所有降级分支必须打日志，且包含原始 SQL 片段、参数哈希、耗时、是否命中缓存——否则下次优化无从下手

降级不是加个 try-except 就完事，关键在超时判定位置、中断信号能否抵达数据库内核、以及下游敢不敢信任你返回的“妥协结果”。这三个点没对齐，再多的装饰器和中间件都是纸糊的闸门。